rename open_issues.mdwn to service_solahart_jakarta_selatan__082122541663.mdwn

1 files changed, 0 insertions, 226 deletions

diff --git a/open_issues/performance/microkernel_multi-server.mdwn b/open_issues/performance/microkernel_multi-server.mdwn
deleted file mode 100644
index 0382c835..00000000
--- a/open_issues/performance/microkernel_multi-server.mdwn
+++ /dev/null
@@ -1,226 +0,0 @@
-[[!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