diff options
Diffstat (limited to 'service_solahart_jakarta_selatan__082122541663/performance/microkernel_multi-server.mdwn')
| -rw-r--r-- | service_solahart_jakarta_selatan__082122541663/performance/microkernel_multi-server.mdwn | 226 |
1 files changed, 226 insertions, 0 deletions
diff --git a/service_solahart_jakarta_selatan__082122541663/performance/microkernel_multi-server.mdwn b/service_solahart_jakarta_selatan__082122541663/performance/microkernel_multi-server.mdwn new file mode 100644 index 00000000..0382c835 --- /dev/null +++ b/service_solahart_jakarta_selatan__082122541663/performance/microkernel_multi-server.mdwn @@ -0,0 +1,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 |