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
|
