summaryrefslogtreecommitdiff
path: root/open_issues/performance
diff options
context:
space:
mode:
Diffstat (limited to 'open_issues/performance')
-rw-r--r--open_issues/performance/io_system/read-ahead.mdwn10
-rw-r--r--open_issues/performance/microkernel_multi-server.mdwn183
2 files changed, 191 insertions, 2 deletions
diff --git a/open_issues/performance/io_system/read-ahead.mdwn b/open_issues/performance/io_system/read-ahead.mdwn
index cd39328f..05a58f2e 100644
--- a/open_issues/performance/io_system/read-ahead.mdwn
+++ b/open_issues/performance/io_system/read-ahead.mdwn
@@ -3031,3 +3031,13 @@ License|/fdl]]."]]"""]]
<mcsim> so, add?
<braunr> if that's what you want to do, ok
<braunr> i'll think about your initial question tomorrow
+
+
+## IRC, freenode, #hurd, 2013-09-30
+
+ <antrik> talking about which... did the clustered I/O work ever get
+ concluded?
+ <braunr> antrik: yes, mcsim was able to finish clustered pageins, and it's
+ still on my TODO list
+ <braunr> it will get merged eventually, now that the large store patch has
+ also been applied
diff --git a/open_issues/performance/microkernel_multi-server.mdwn b/open_issues/performance/microkernel_multi-server.mdwn
index 111d2b88..0382c835 100644
--- a/open_issues/performance/microkernel_multi-server.mdwn
+++ b/open_issues/performance/microkernel_multi-server.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!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
@@ -12,7 +12,8 @@ License|/fdl]]."]]"""]]
Performance issues due to the microkernel/multi-server system architecture?
-IRC, freenode, #hurd, 2011-07-26
+
+# 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 ?
@@ -45,3 +46,181 @@ IRC, freenode, #hurd, 2011-07-26
< 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