Hi Josh, On 3.5.2012 9:35, Josh Haberman wrote: > Hi everyone, I recently discovered HelenOS and was very happy to see its > design philosophy and approach! I am a big fan of your principles: a > truly decoupled design, breaking with POSIX, and the "breadth first" > design approach.
Thanks for your interest in HelenOS, it's always nice to see new fans coming. > One thing I was curious about as I started studying its design: why put > async IPC in the kernel? My impression was that one of L4's major > innovations was putting only synchronous IPC in the kernel, which > simplifies the kernel and increases performance. Async IPC sounds like > a more Mach-like design, with associated problems of queuing. Can't > async IPC/queueing be implemented in user-space on top of a kernel-based > sync IPC? The L4 'innovations' date back to the 90's, the era of painfully slow uniprocessor machines. In the era of superfast machines with much more parallelism, async IPC can have some benefits too. For example, you can do some useful work between sending the request and waiting for the reply. Sync IPC has its own problems. There are papers describing various vulnerabilities in syncrhonous IPC communication caused by one party not actively participating in it. I believe there are also performance related issues with sync IPC, such as two TLB flushes per each RPC on dumb architectures (say on amd64 without ASIDs if the client and server run on the same CPU). With async, you can group requests and send them in one batch before waiting for the replies, so that there can be only two TLB flushes for all this IPC communication. In the Liedtke's '93 paper 'Improving IPC by Kernel Design', there is a chart in section 5.6, which says what is the impact of each optimization on the performance. Surprisingly, the best optimizations are not related to the synchronous nature of the L3 IPC. Instead, the best improvements seem to be passing IPC arguments in registers and passing large messages via memory sharing. I also think, that the L4's focus on performance is not that important these days. The system needs not be the fastest, it may suffice if it is fast enough for its purpose. There can be more important goals, such as portability. You are right that having both the async and sync IPC in the kernel does not meet the requirement for the minimalistic kernel as stated by IIRC prof. Liedtke. However, I have always perceived that requirement to be rather unilaterally demanded by the L4 people and I never felt like HelenOS should abide by it. I remember reading Stefan Götz's master thesis 'Asynchronous Communication Using Synchronous IPC Primitives'. It's been some time since I read it, but he basically adds asynchronous IPC to L4 by building the uspace asynchronous IPC on top of the kernel synchronous IPC. In my opinion, this is suboptimal and smells with the abstraction inversion antipattern. A more natural choice would be to do it the other way around: build synchronous from asynchronous. In HelenOS, the kernel provides both sync and async IPC syscalls. Both syscall variants are based on the same underlying kernel IPC mechanism, which is fundamentally asynchronous. To illustrate this, the synchronous variant just sends the request (asynchronously) and then immediately waits for the reply. These days, the HelenOS uspace does not make much use of the sync IPC syscalls anymore. It predominantly uses the async framework and thus async IPC syscalls. Again, on top of the async IPC syscalls, the async framework provides asynchronous (but without callbacks) and synchronous (send & wait) communication. Cheers, Jakub _______________________________________________ HelenOS-devel mailing list [email protected] http://lists.modry.cz/cgi-bin/listinfo/helenos-devel
