3 ms·

FUSE is what a microkernel filesystem would look like. There are some optimisations that FUSE doesn't do, that microkernels usually have. In the most extreme fo

FUSE is what a microkernel filesystem would look like. There are some optimisations that FUSE doesn't do, that microkernels usually have. In the most extreme form, L4 trims down communication primitives to the most efficient platform-specific ways of exchanging memory buffers. In all cases, microkernels and FUSE still need context switches for everything, and those are expensive. If you leave out the context switches, you don't have a microkernel anymore. This is what Windows did by pulling graphics drivers into the kernel, because context switches are slow. So no. Microkernels have been tried. Microkernel-workalike filesystems are here with FUSE. They suck because microkernels suck when you need performance. Research has gone into different directions, like microkernels as hypervisors and for security, because it has become clear that the performance problems if microkernels are inherent and unfixable.

Dylan16807 1y ago
> because it has become clear that the performance problems if microkernels are inherent and unfixable. I don't get the impression that CPU designers have been putting a particularly large focus on making context switches fast. They try but they're busy doing everything else too. If context switches were constant I think silicon would make them go a lot faster.
- holowoodman 1y ago
  One thing is that context switches have become less of a problem with the advent of multicore systems. But we are not at a place where you can have your dedicated filesystem core for each filesystem, so they are still relevant. And yes, CPUs are generally optimized not for context switches, but for numerics and certain single-application benchmarks. So computations without any context switches are very fast. Application to Kernel switches are somewhat fast as well. But application-to-application or even worse application-kernel-privilegedFSprocess-kernel-application will be slow as hell, because those numbers never make it to the TOP500 or benchmark sites. Context switches also have already been optimized too much, Spectre and Meltdown in all their variants are a certain kind of botched context switch. That means that certain optimizations are now out of the question, context switches will be optimized more carefully (if at all) in the future. So there isn't too much hope for a faster but still secure context switch. I think the actual future in a decade or so will rather have more cores, less context switches and a more computer-network-like CPU. You will have your filesystem server process on the filesystem/disk-IO core and you will speak some filesystem protocol via shared memory over a on-CPU network.

Dylan16807 1y ago

> because it has become clear that the performance problems if microkernels are inherent and unfixable. I don't get the impression that CPU designers have been putting a particularly large focus on making context switches fast. They try but they're busy doing everything else too. If context switches were constant I think silicon would make them go a lot faster.

holowoodman 1y ago
One thing is that context switches have become less of a problem with the advent of multicore systems. But we are not at a place where you can have your dedicated filesystem core for each filesystem, so they are still relevant. And yes, CPUs are generally optimized not for context switches, but for numerics and certain single-application benchmarks. So computations without any context switches are very fast. Application to Kernel switches are somewhat fast as well. But application-to-application or even worse application-kernel-privilegedFSprocess-kernel-application will be slow as hell, because those numbers never make it to the TOP500 or benchmark sites. Context switches also have already been optimized too much, Spectre and Meltdown in all their variants are a certain kind of botched context switch. That means that certain optimizations are now out of the question, context switches will be optimized more carefully (if at all) in the future. So there isn't too much hope for a faster but still secure context switch. I think the actual future in a decade or so will rather have more cores, less context switches and a more computer-network-like CPU. You will have your filesystem server process on the filesystem/disk-IO core and you will speak some filesystem protocol via shared memory over a on-CPU network.