[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 10:07:58 PDT 2013

On May 21, 2013, at 8:55 AM, Stephen Williams <sdw at lig.net> wrote:
> I was talking here about the synchronization between an application thread and a device driver.  They both need to read/write, ideally without context switches and minimal interrupts / blocking.

Remember, you've taken control of process scheduling and I/O scheduling, and modern hardware has well-behaved DMA implementations. The schedule is completely cooperative so there is no need for locking per se. Contended access between threads and hardware usually never happens because the schedulers never schedule them concurrently when contention could occur. The application has enough context to schedule around conflicts without using a lock to arbitrate. 

It is a barrel processor implemented in software.

> As an example of something important in the past, scatter / gather on SSD isn't going to be a big improvement as it can be for SCSI (and presumably SATA, which is essentially SCSI).  The SSD has no rotational latency or heads to move so it probably can return responses in the same order as they were given.

SSDs have their own complex behaviors on par with HDDs. The notion that they offer uniform random access behavior is valid to a first approximation for light users but does not hold up for I/O intensive applications (like databases). SSDs work much better if you have several I/Os in flight that can be processed out of order.

>> Exokernel application skeletons are really neat pieces of elegant software with very dense functional complexity. Nothing quite like it in software. It is basically an OS kernel with none of the device driver stuff to worry about. (I've designed exokernel applications, we just didn't use the term "exokernel".)
> Running as an app under another kernel that has virtualized device drivers?

Yep. The kernel has an uncanny ability to usually do the optimal thing from the app's perspective.

More information about the FoRK mailing list