3 ms·

Well the good news is that now microkernels can take over. With KPTI (also known as FUCKWIT), a syscall is now as expensive as a context switch to another userl

Well the good news is that now microkernels can take over. With KPTI (also known as FUCKWIT), a syscall is now as expensive as a context switch to another userland process. Of course, that means now monolithic kernels run just as slow as microkernels.

astrange 9y ago
Recent Intel CPUs have PCID (TLB tagged by process ID), which makes KPTI not much slower than what we had last week.
JdeBP 9y ago
I suggest some reading first, starting with (but not limited to): * http://blog.darknedgy.net/technology/2016/01/01/0/ http://blog.darknedgy.net/technology/2016/01/01/0/ (https://news.ycombinator.com/item?id=10824382 https://news.ycombinator.com/item?id=10824382) * https://news.ycombinator.com/item?id=10483467 https://news.ycombinator.com/item?id=10483467
- kuschku 9y ago
  I've read them — but the important factor is that Linux with KPTI is now doing a full context switch between userland and kernel, which is the same cost as switching to another userland process to handle the syscall (which is exactly what a naive microkernel would do). I've always been a proponent of microkernels, and this is another situation that might help with this. (Personally, I've been affected by the failures of monolithic kernels way too often. When a simple OpenGL or WebGL program manages to hang your GPU driver, parts of the kernel, and all DMA operations in the kernel, and your system becomes unusable, then reasonable isolation would be preferable)
Symmetry 9y ago
The performance differential is a concern with classical microkernel designs but not really with modern ones. The process isolation is useful when dealing with Meltdown but not with Spectre.
hinkley 9y ago
Hypervisors and containers already blur this line. I think we were heading there anyway. But a microkernel is going to have multiple processes talking to each other, so there will still be more overhead whenever a message requires coordination between more than two processes.

astrange 9y ago

Recent Intel CPUs have PCID (TLB tagged by process ID), which makes KPTI not much slower than what we had last week.

JdeBP 9y ago

I suggest some reading first, starting with (but not limited to): * http://blog.darknedgy.net/technology/2016/01/01/0/ http://blog.darknedgy.net/technology/2016/01/01/0/ (https://news.ycombinator.com/item?id=10824382 https://news.ycombinator.com/item?id=10824382) * https://news.ycombinator.com/item?id=10483467 https://news.ycombinator.com/item?id=10483467

kuschku 9y ago
I've read them — but the important factor is that Linux with KPTI is now doing a full context switch between userland and kernel, which is the same cost as switching to another userland process to handle the syscall (which is exactly what a naive microkernel would do). I've always been a proponent of microkernels, and this is another situation that might help with this. (Personally, I've been affected by the failures of monolithic kernels way too often. When a simple OpenGL or WebGL program manages to hang your GPU driver, parts of the kernel, and all DMA operations in the kernel, and your system becomes unusable, then reasonable isolation would be preferable)

Symmetry 9y ago

The performance differential is a concern with classical microkernel designs but not really with modern ones. The process isolation is useful when dealing with Meltdown but not with Spectre.

hinkley 9y ago

Hypervisors and containers already blur this line. I think we were heading there anyway. But a microkernel is going to have multiple processes talking to each other, so there will still be more overhead whenever a message requires coordination between more than two processes.