[FoRK] [info] (highscalability.com) The Secret to 10 Million Concurrent Connections -The Kernel is the Problem, Not the Solution

J. Andrew Rogers andrew at jarbox.org
Tue May 21 09:25:14 PDT 2013


On May 21, 2013, at 1:40 AM, Eugen Leitl <eugen at leitl.org> wrote:
> On Mon, May 20, 2013 at 02:48:24PM -0700, J. Andrew Rogers wrote:
> 
>> This is relatively new. Five years ago Linux did not support exokernel
>> application models. Designing applications this way requires a pretty
>> high-end level of software engineering know-how hence the rarity of code
>> designed for this model.
> 
> You're not talking about L4 here, are you?


No, nothing like that. I am talking about a standard but moderately recent Linux kernel. 

Linux has been accumulating facilities to do kernel bypass for most things the kernel is conventionally responsible for by pushing responsibility into user space, either directly or indirectly. Database companies like Oracle have often been the drivers of these features. The kernel ends up not doing much more than abstracting hardware, maintaining an event state machine for the hardware (which is still mostly user space), permissions, and managing transfer of resource ownership to the applications. 

By comparison, this is not possible on many other UNIX systems e.g. MacOS. 

It is not a true "exokernel" environment but you can use it like it is by pushing almost everything the kernel does into the application. That includes process creation and process scheduling, memory management, disk management, I/O scheduling and buffering, etc. Unlike a pure exokernel, it is often useful in practice to not bypass the kernel for a few things where the effort is not justified by the benefit. An example of that is managing filesystem metadata; it is easier to reduce the number of filesystem metadata operations to a very bare minimum and accept the possibility of "wrong" behavior in the rare cases where such operations occur.





More information about the FoRK mailing list