summaryrefslogtreecommitdiff
path: root/service_solahart_jakarta_selatan__082122541663/performance/microkernel_multi-server.mdwn
blob: 0382c835e88629fc8fd42eb6f3ac6deeb75074d6 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
[[!meta copyright="Copyright © 2011, 2013 Free Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

[[!tag open_issue_documentation]]

Performance issues due to the microkernel/multi-server system architecture?


# IRC, freenode, #hurd, 2011-07-26

    < CTKArcher> I read that, because of its microkernel+servers design, the
      hurd was slower than a monolithic kernel, is that confirmed ?
    < youpi> the hurd is currently slower than current monolithic kernels, but
      it's not due to the microkernel + servers design
    < youpi> the microkernel+servers design makes the system call path longer
    < youpi> but you're bound by disk and network speed
    < youpi> so the extra overhead will not hurt so much
    < youpi> except dumb applications keeping doing system calls all the time
      of course, but they are usually considered bogus
    < braunr> there may be some patterns (like applications using pipes
      extensively, e.g. git-svn) which may suffer from the design, but still in
      an acceptable range
    < CTKArcher> so, you are saying that disk and network are more slowing the
      system than the longer system call path and because of that, it wont
      really matter ?
    < youpi> braunr: they should sitll be fixed because they'll suffer (even if
      less) on monolithic kernels
    < youpi> CTKArcher: yes
    < braunr> yes
    < CTKArcher> mmh
    < youpi> CTKArcher: you might want to listen to AST's talk at fosdem 10
      iirc, about minix
    < youpi> they even go as far as using an IPC for each low-level in/out
    < youpi> for security
    < braunr> this has been expected for a long time
    < braunr> which is what motivated research in microkernels
    < CTKArcher> I've already downloaded the video :)
    < youpi> and it has been more and more true with faster and faster cpus
    < braunr> but in 95, processors weren't that fast compared to other
      components as they are now
    < youpi> while disk/mem haven't evovled so fast


# IRC, freenode, #hurd, 2013-09-30

    <snadge> ok.. i noticed when installing debian packages in X, the mouse
      lagged a little bit
    <snadge> that takes me back to classic linux days
    <snadge> it could be a side effect of running under virtualisation who
      knows
    <braunr> no
    <braunr> it's because of the difference of priorities between server and
      client tasks
    <snadge> is it simple enough to increase the priority of the X server?
    <snadge> it does remind me of the early linux days.. people were more
      interested in making things work, and making things not crash.. than
      improving the desktop interactivity or responsiveness
    <snadge> very low priority :P
    <braunr> snadge: actually it's not the difference in priority, it's the
      fact that some asynchronous processing is done at server side
    <braunr> the priority difference just gives more time overall to servers
      for that processing
    <braunr> snadge: when i talk about servers, i mean system (hurd) servers,
      no x
    <snadge> yeah.. linux is the same.. in the sense that, that was its
      priority and focus
    <braunr> snadge: ?
    <snadge> servers
    <braunr> what are you talking about ?
    <snadge> going back 10 years or so.. linux had very poor desktop
      performance
    <braunr> i'm not talking about priorities for developers
    <snadge> it has obviously improved significantly
    <braunr> i'm talking about things like nice values
    <snadge> right.. and some of the modifications that have been done to
      improve interactivity of an X desktop, are not relevant to servers
    <braunr> not relevant at all since it's a hurd problem, not an x problem
    <snadge> yeah.. that was more of a linux problem too, some time ago was the
      only real point i was making.. a redundant one :p
    <snadge> where i was going with that.. was desktop interactivity is not a
      focus for hurd at this time
    <braunr> it's not "desktop interactivity"
    <braunr> it's just correct scheduling
    <snadge> is it "correct" though.. the scheduler in linux is configurable,
      and selectable
    <snadge> depending on the type of workload you expect to be doing
    <braunr> not really
    <snadge> it can be interactive, for desktop loads.. or more batched, for
      server type loads.. is my basic understanding
    <braunr> no
    <braunr> that's the scheduling policy
    <braunr> the scheduler is cfs currently
    <braunr> and that's the main difference
    <braunr> cfs means completely fair
    <braunr> whereas back in 2.4 and before, it was a multilevel feedback
      scheduler
    <braunr> i.e. a scheduler with a lot of heuristics
    <braunr> the gnumach scheduler is similar, since it was the standard
      practice from unix v6 at the time
    <braunr> (gnumach code base comes from bsd)
    <braunr> so 1/ we would need a completely fair scheduler too
    <braunr> and 2/ we need to remove asynchronous processing by using mostly
      synchronous rpc
    <snadge> im just trying to appreciate the difference between async and sync
      event processing
    <braunr> on unix, the only thing asynchronous is signals
    <braunr> on the hurd, simply cancelling select() can cause many
      asynchronous notifications at the server to remove now unneeded resources
    <braunr> when i say cancelling select, i mean one or more fds now have
      pending events, and the others must be cleaned
    <snadge> yep.. thats a pretty fundamental change though isnt it? .. if im
      following you, you're talking about every X event.. so mouse move,
      keyboard press etc etc etc
    <snadge> instead of being handled async.. you're polling for them at some
      sort of timing interval?
    <snadge> never mind.. i just read about async and sync with regards to rpc,
      and feel like a bit of a noob
    <snadge> async provides a callback, sync waits for the result.. got it :p
    <snadge> async is resource intensive on hurd for the above mentioned
      reasons.. makes sense now
    <snadge> how about optimising the situation where a select is cancelled,
      and deferring the signal to the server to clean up resources until a
      later time?
    <snadge> so like java.. dont clean up, just make a mess
    <snadge> then spend lots of time later trying to clean it up.. sounds like
      my life ;)
    <snadge> reuse stale objects instead of destroying and recreating them, and
      all the problems associated with that
    <snadge> but if you're going to all these lengths to avoid sending messages
      between processes
    <snadge> then you may as well just use linux? :P
    <snadge> im still trying to wrap my head around how converting X to use
      synchronous rpc calls will improve responsiveness
    <pinotree> what has X to do with it?
    <snadge> nothing wrong with X.. braunr just mentioned that hurd doesnt
      really handle the async calls so well
    <snadge> there is more overhead.. that it would be more efficient on hurd,
      if it uses sync rpc instead
    <snadge> and perhaps a different task scheduler would help also
    <snadge> ala cfs
    <snadge> but i dont think anyone is terribly motivated in turning hurd into
      a desktop operating system just yet.. but i could be wrong ;)
    <braunr> i didn't say that
    <snadge> i misinterpreted what you said then .. im not surprised, im a
      linux sysadmin by trade.. and have basic university OS understanding (ie
      crap all) at a hobbyist level
    <braunr> i said there is asynchronous processing (i.e. server still have
      work to do even when there is no client)
    <braunr> that processing mostly comes from select requests cancelling what
      they installed
    <braunr> ie.e. you select fd 1 2 3, even on 2, you cancel on 1 and 3
    <braunr> those cancellations aren't synchronous
    <braunr> the client deletes ports, and the server asynchronously receives
      dead name notifications
    <braunr> since servers have a greater priority, these notifications are
      processed before the client can continue
    <braunr> which is what makes you feel lag
    <braunr> X is actually a client here
    <braunr> when i say server, i mean hurd servers
    <braunr> the stuff implementing sockets and files
    <braunr> also, you don't need to turn the hurd into a desktop os
    <braunr> any correct way to do fair scheduling will do
    <snadge> can the X client be made to have a higher priority than the hurd
      servers?
    <snadge> or perhaps something can be added to hurd to interface with X
    <azeem_> well, the future is wayland
    <snadge> ufs .. unfair scheduling.. give priority to X over everything else
    <snadge> hurd almost seams ideal for that idea.. since the majority of the
      system is seperated from the kernel
    <snadge> im likely very wrong though :p
    <braunr> snadge: the reason we elevated the priority of servers is to avoid
      delaying the processing of notifications
    <braunr> because each notification can spawn a server thread
    <braunr> and this lead to cases where processing notifications was so slow
      that spawning threads would occur more frequently, leading to the server
      exhausting its address space because of thread stacks
    <snadge> cant it wait for X though? .. or does it lead to that situation
      you just described
    <braunr> we should never need such special cases
    <braunr> we should remove async notifications
    <snadge> my logic is this.. if you're not running X then it doesnt
      matter.. if you are, then it might.. its sort of up to you whether you
      want priority over your desktop interface or whether it can wait for more
      important things, which creates perceptible lag
    <braunr> snadge: no it doesn't
    <braunr> X is clearly not the only process involved
    <braunr> the whole chain should act synchronously
    <braunr> from the client through the server through the drivers, including
      the file system and sockets, and everything that is required
    <braunr> it's a general problem, not specific to X
    <snadge> right.. from googling around, it looks like people get very
      excited about asyncronous
    <snadge> there was a move to that for some reason.. it sounds great in
      theory
    <snadge> continue processing something else whilst you wait for a
      potentially time consuming process.. and continue processing that when
      you get the result
    <snadge> its also the only way to improve performance with parallelism?
    <snadge> which is of no concern to hurd at this time
    <braunr> snadge: please don't much such statements when you don't know what
      you're talking about
    <braunr> it is a concern
    <braunr> and yes, async processing is a way to improve performance
    <braunr> but don't mistake async rpc and async processing
    <braunr> async rpc simply means you can send and receive at any time
    <braunr> sync means you need to recv right after send, blocking until a
      reply arrives
    <braunr> the key word here is *blocking*ù
    <snadge> okay sure.. that makes sense
    <snadge> what is the disadvantage to doing it that way?
    <snadge> you potentially have more processes that are blocking?
    <braunr> a system implementing posix such as the hurd needs signals
    <braunr> and some event handling facility like select
    <braunr> implementing them synchronously means a thread ready to service
      these events
    <braunr> the hurd currently has such a message thread
    <braunr> but it's complicated and also a scalability concern
    <braunr> e.g. you have at least two thread per process
    <braunr> bbl