4 ms·

>but they're a concept ahead of current hardware design How so? >they don't really bring the flexibility typically promised. Which ones have you tried?

• Rusky 12y ago
  On current hardware, RPC is expensive no matter how you optimize it because it goes through the kernel. It could be even cheaper than system calls with better context-switching primitives (tagged TLB or single address space, context switching directly from user-space, etc.) I have played a lot with L4, but the flexibility problems I'm talking about are intrinsic to the traditional microkernel organization. Any user or application can't replace a privileged system server- they can replace a shared library.
  • haberman 12y ago
    > Any user or application can't replace a privileged system server- they can replace a shared library. In my view, "privileged system servers" should only exist inasmuch as they are necessary to be an arbiter of resources or a router of hardware messages. Take memory: at some level, something has to have authority over which of several competing processes will get ownership of memory pages. And when a page fault occurs for some virtual memory page, there has to be some way of dispatching this to the code that can handle it without triggering a page fault itself. Both of these cases require centralized, privileged processes by nature. Anything else that does not similarly require centralized privileged processes are better handled as shared library, I agree. I'm not sure I see what parts of the "traditional microkernel organization" mandate privileged system servers for things. I haven't looked at L4 in a while, but as I recall the only server that is inherently privileged is a pager, which must be privileged for the two reasons I mentioned before.
    • Rusky 12y ago
      Yes. I don't know much about how servers are typically done today, but from the research I've read server processes are used for things like file systems, the network stack, virtual memory swapping, or other abstractions on top of the hardware, in addition to L4's user space drivers. However, these servers don't have the right domain-specific knowledge. For example, when the kernel (or a server) needs to revoke some physical memory from a process, it doesn't have the information it needs to do this well- LRU-page-to-disk is not always the best pattern. A database application could instead discard an index page if regenerating it is faster than loading it from disk- this is faster and more power efficient. When the kernel needs to allocate disk space to a file system, it doesn't know the expected usage of that space as well as the application often can. Databases, web servers, version control, etc, all know (or can profile) their file system usage (for that matter, the file system itself is sometimes suboptimal)- "this web page will also send these js, css, and image files" for example, so letting the application choose the disk blocks out of the available ones can bring massive performance improvements. The same applies to network packet merging, file copy operations, scheduling of threads in an application, using the virtual memory system for things like garbage collection and persistent storage, etc.
  • copergi 12y ago
    >On current hardware, RPC is expensive no matter how you optimize You mean IPC? While hardware support could make it faster, it is already plenty fast. The whole "L4 only introduces 3% overhead" thing is pretty old news at this point. >I have played a lot with L4 Then you should know that the performance myths that come from mach's slowness are not accurate. >Any user or application can't replace a privileged system server Multi-user systems are a vanishingly small minority at this point. I don't think "you need to be in control of your computer" is a huge show stopper.
    • Rusky 12y ago
      I mean RPC, because that is the common use case of IPC between applications and servers in microkernel systems. It is more expensive than shared library calls or system calls no matter how much you optimize it on current architectures. I'm also well aware of L4's performance vs Mach, but like I said: "instead of the lingering 'eh, it's a little slower but we can ignore that,' exokernels provide much better opportunities for optimization and tend to be much faster" than monolithic or microkernel designs. For example, MIT's Cheetah HTTP static file server (comparable to squid, at the time named Harvest) achieved a 4x performance improvement just by moving to an exokernel and an 8x performance improvement by implementing some of the optimizations I've described in previous comments. This depends on the ability to bypass the privileged servers a microkernel typically uses. Microkernels are nice for security, for a few percent overhead, and that's good, but that's about all they do, so they're not seen as worthwhile for many uses. Exokernels can provide the same level of security while also providing far greater flexibility and performance. This essentially provides, with a performance gain, what current data centers use virtualization for, which is another few-percent-slowdown.
      • copergi 12y ago
        I can't tell if that is the most subtle trolling I've seen since the 90s, or if you are seriously saying "yes I know I was lying, but I am still lying so it is cool".