diff options
Diffstat (limited to 'microkernel/mach/deficiencies.mdwn')
| -rw-r--r-- | microkernel/mach/deficiencies.mdwn | 262 |
1 files changed, 262 insertions, 0 deletions
diff --git a/microkernel/mach/deficiencies.mdwn b/microkernel/mach/deficiencies.mdwn index f2f49975..e1f6debc 100644 --- a/microkernel/mach/deficiencies.mdwn +++ b/microkernel/mach/deficiencies.mdwn @@ -258,3 +258,265 @@ License|/fdl]]."]]"""]] working on research around mach <antrik> braunr: BTW, I have little doubt that making RPC first-class would solve a number of problems... I just wonder how many others it would open + + +# IRC, freenode, #hurd, 2012-09-04 + +X15 + + <braunr> it was intended as a mach clone, but now that i have better + knowledge of both mach and the hurd, i don't want to retain mach + compatibility + <braunr> and unlike viengoos, it's not really experimental + <braunr> it's focused on memory and cpu scalability, and performance, with + techniques likes thread migration and rcu + <braunr> the design i have in mind is closer to what exists today, with + strong emphasis on scalability and performance, that's all + <braunr> and the reason the hurd can't be modified first is that my design + relies on some important design changes + <braunr> so there is a strong dependency on these mechanisms that requires + the kernel to exists first + + +## IRC, freenode, #hurd, 2012-09-06 + +In context of [[open_issues/multithreading]] and later [[open_issues/select]]. + + <gnu_srs> And you will address the design flaws or implementation faults + with x15? + <braunr> no + <braunr> i'll address the implementation details :p + <braunr> and some design issues like cpu and memory resource accounting + <braunr> but i won't implement generic resource containers + <braunr> assuming it's completed, my work should provide a hurd system on + par with modern monolithic systems + <braunr> (less performant of course, but performant, scalable, and with + about the same kinds of problems) + <braunr> for example, thread migration should be mandatory + <braunr> which would make client calls behave exactly like a userspace task + asking a service from the kernel + <braunr> you have to realize that, on a monolithic kernel, applications are + clients, and the kernel is a server + <braunr> and when performing a system call, the calling thread actually + services itself by running kernel code + <braunr> which is exactly what thread migration is for a multiserver system + <braunr> thread migration also implies sync IPC + <braunr> and sync IPC is inherently more performant because it only + requires one copy, no in kernel buffering + <braunr> sync ipc also avoids message floods, since client threads must run + server code + <gnu_srs> and this is not achievable with evolved gnumach and/or hurd? + <braunr> well that's not entirely true, because there is still a form of + async ipc, but it's a lot less likely + <braunr> it probably is + <braunr> but there are so many things to change i prefer starting from + scratch + <braunr> scalability itself probably requires a revamp of the hurd core + libraries + <braunr> and these libraries are like more than half of the hurd code + <braunr> mach ipc and vm are also very complicated + <braunr> it's better to get something new and simpler from the start + <gnu_srs> a major task nevertheless:-D + <braunr> at least with the vm, netbsd showed it's easier to achieve good + results from new code, as other mach vm based systems like freebsd + struggled to get as good + <braunr> well yes + <braunr> but at least it's not experimental + <braunr> everything i want to implement already exists, and is tested on + production systems + <braunr> it's just time to assemble those ideas and components together + into something that works + <braunr> you could see it as a qnx-like system with thread migration, the + global architecture of the hurd, and some improvements from linux like + rcu :) + + +### IRC, freenode, #hurd, 2012-09-07 + + <antrik> braunr: thread migration is tested on production systems? + <antrik> BTW, I don't think that generally increasing the priority of + servers is a good idea + <antrik> in most cases, IPC should actually be sync. slpz looked at it at + some point, and concluded that the implementation actually has a + fast-path for that case. I wonder what happens to scheduling in this case + -- is the receiver sheduled immediately? if not, that's something to + fix... + <braunr> antrik: qnx does something very close to thread migration, yes + <braunr> antrik: i agree increasing the priority isn't a good thing, but + it's the best of the quick and dirty ways to reduce message floods + <braunr> the problem isn't sync ipc in mach + <braunr> the problem is the notifications (in our cases the dead name + notifications) that are by nature async + <braunr> and a malicious program could send whatever it wants at the + fastest rate it can + <antrik> braunr: malicious programs can do any number of DOS attacks on the + Hurd; I don't see how increasing priority of system servers is relevant + in that context + <antrik> (BTW, I don't think dead name notifications are async by + nature... just like for most other IPC, the *usual* case is that a server + thread is actively waiting for the message when it's generated) + <braunr> antrik: it's async with respect to the client + <braunr> antrik: and malicious programs shouldn't be able to do that kind + of dos + <braunr> but this won't be fixed any time soon + <braunr> on the other hand, a higher priority helps servers not create too + many threads because of notifications, and that's a good thing + <braunr> gnu_srs: the "fix" for this will be to rewrite select so that it's + synchronous btw + <braunr> replacing dead name notifications with something like cancelling a + previously installed select request + <antrik> no idea what "async with respect to the client" means + <braunr> it means the client doesn't wait for anything + <antrik> what is the client? what scenario are you talking about? how does + it affect scheduling? + <braunr> for notifications, it's usually the kernel + <braunr> it doesn't directly affect scheduling + <braunr> it affects the amount of messages a hurd server has to take care + of + <braunr> and the more messages, the more threads + <braunr> i'm talking about event loops + <braunr> and non blocking (or very short) selects + <antrik> the amount of messages is always the same. the question is whether + they can be handled before more come in. which would be the case if be + default the receiver gets scheduled as soon as a message is sent... + <braunr> no + <braunr> scheduling handoff doesn't imply the thread will be ready to + service the next message by the time a client sends a new one + <braunr> the rate at which a message queue gets filled has nothing to do + with scheduling handoff + <antrik> I very much doubt rates come into play at all + <braunr> well they do + <antrik> in my understanding the problem is that a lot of messages are sent + before the receive ever has a chance to handle them. so no matter how + fast the receiver is, it looses + <braunr> a lot of non blocking selects means a lot of reply ports + destroyed, a lot of dead name notifications, and what i call message + floods at server side + <braunr> no + <braunr> it used to work fine with cthreads + <braunr> it doesn't any more with pthreads because pthreads are slightly + slower + <antrik> if the receiver gets a chance to do some work each time a message + arrives, in most cases it would be free to service the next request with + the same thread + <braunr> no, because that thread won't have finished soon enough + <antrik> no, it *never* worked fine. it might have been slighly less + terrible. + <braunr> ok it didn't work fine, it worked ok + <braunr> it's entirely a matter of rate here + <braunr> and that's the big problem, because it shouldn't + <antrik> I'm pretty sure the thread would finish before the time slice ends + in almost all cases + <braunr> no + <braunr> too much contention + <braunr> and in addition locking a contended spin lock depresses priority + <braunr> so servers really waste a lot of time because of that + <antrik> I doubt contention would be a problem if the server gets a chance + to handle each request before 100 others come in + <braunr> i don't see how this is related + <braunr> handling a request doesn't mean entirely processing it + <braunr> there is *no* relation between handoff and the rate of incoming + message rate + <braunr> unless you assume threads can always complete their task in some + fixed and low duration + <antrik> sure there is. we are talking about a single-processor system + here. + <braunr> which is definitely not the case + <braunr> i don't see what it changes + <antrik> I'm pretty sure notifications can generally be handled in a very + short time + <braunr> if the server thread is scheduled as soon as it gets a message, it + can also get preempted by the kernel before replying + <braunr> no, notifications can actually be very long + <braunr> hurd_thread_cancel calls condition_broadcast + <braunr> so if there are a lot of threads on that .. + <braunr> (this is one of the optimizations i have in mind for pthreads, + since it's possible to precisely select the target thread with a doubly + linked list) + <braunr> but even if that's the case, there is no guarantee + <braunr> you can't assume it will be "quick enough" + <antrik> there is no guarantee. but I'm pretty sure it will be "quick + enough" in the vast majority of cases. which is all it needs. + <braunr> ok + <braunr> that's also the idea behind raising server priorities + <antrik> braunr: so you are saying the storms are all caused by select(), + and once this is fixed, the problem should be mostly gone and the + workaround not necessary anymore? + <braunr> yes + <antrik> let's hope you are right :-) + <braunr> :) + <antrik> (I still think though that making hand-off scheduling default is + the right thing to do, and would improve performance in general...) + <braunr> sure + <braunr> well + <braunr> no it's just a hack ;p + <braunr> but it's a right one + <braunr> the right thing to do is a lot more complicated + <braunr> as roland wrote a long time ago, the hurd doesn't need dead-name + notifications, or any notification other than the no-sender (which can be + replaced by a synchronous close on fd like operation) + <antrik> well, yes... I still think the viengoos approach is promising. I + meant the right thing to do in the existing context ;-) + <braunr> better than this priority hack + <antrik> oh? you happen to have a link? never heard of that... + <braunr> i didn't want to do it initially, even resorting to priority + depression on trhead creation to work around the problem + <braunr> hm maybe it wasn't him, i can't manage to find it + <braunr> antrik: + http://lists.gnu.org/archive/html/l4-hurd/2003-09/msg00009.html + <braunr> "Long ago, in specifying the constraints of + <braunr> what the Hurd needs from an underlying IPC system/object model we + made it + <braunr> very clear that we only need no-senders notifications for object + <braunr> implementors (servers)" + <braunr> "We don't in general make use of dead-name notifications, + <braunr> which are the general kind of object death notification Mach + provides and + <braunr> what serves as task death notification." + <braunr> "In the places we do, it's to serve + <braunr> some particular quirky need (and mostly those are side effects of + Mach's + <braunr> decouplable RPCs) and not a semantic model we insist on having." + + +### IRC, freenode, #hurd, 2012-09-08 + + <antrik> The notion that seemed appropriate when we thought about these + issues for + <antrik> Fluke was that the "alert" facility be a feature of the IPC system + itself + <antrik> rather than another layer like the Hurd's io_interrupt protocol. + <antrik> braunr: funny, that's *exactly* what I was thinking when looking + at the io_interrupt mess :-) + <antrik> (and what ultimately convinced me that the Hurd could be much more + elegant with a custom-tailored kernel rather than building around Mach) + + +## IRC, freenode, #hurd, 2012-09-24 + + <braunr> my initial attempt was a mach clone + <braunr> but now i want a mach-like kernel, without compability + <lisporu> which new licence ? + <braunr> and some very important changes like sync ipc + <braunr> gplv3 + <braunr> (or later) + <lisporu> cool 8) + <braunr> yes it is gplv2+ since i didn't take the time to read gplv3, but + now that i have, i can't use anything else for such a project: ) + <lisporu> what is mach-like ? (how it is different from Pistachio like ?) + <braunr> l4 doesn't provide capabilities + <lisporu> hmmm.. + <braunr> you need a userspace for that + <braunr> +server + <braunr> and it relies on complete external memory management + <lisporu> how much work is done ? + <braunr> my kernel will provide capabilities, similar to mach ports, but + simpler (less overhead) + <braunr> i want the primitives right + <braunr> like multiprocessor, synchronization, virtual memory, etc.. + + +### IRC, freenode, #hurd, 2012-09-30 + + <braunr> for those interested, x15 is now a project of its own, with no + gnumach compability goal, and covered by gplv3+ |