2 ms·

I would like to qualify that seL4 (and the entire family of L4 kernels) were created exactly to disprove the idea that microkernels were slow. They are extremel

I would like to qualify that seL4 (and the entire family of L4 kernels) were created exactly to disprove the idea that microkernels were slow. They are extremely perfomant. The idea that microkernels are slow came from analyzing a popular microkernel at the time - mach. It in no way is a true blanket statement for all microkernels. edit: found a good comparison chart (first link) https://sigops.org/s/conferences/sosp/2013/talks/elphinstone_l3sel4_se03_03.pdf https://sigops.org/s/conferences/sosp/2013/talks/elphinstone... https://sel4.systems/About/seL4-whitepaper.pdf https://sel4.systems/About/seL4-whitepaper.pdf https://sel4.systems/performance.html https://sel4.systems/performance.html https://dl.acm.org/doi/10.1145/173668.168633 https://dl.acm.org/doi/10.1145/173668.168633 https://en.wikipedia.org/wiki/L4_microkernel_family https://en.wikipedia.org/wiki/L4_microkernel_family

gucci-on-fleek 10mo ago
> The idea that microkernels are slow came from analyzing a popular microkernel at the time - mach. It in no way is a true blanket statement for all microkernels. Don't microkernels inherently require lots of context switches between kernel-space and user-space, which are especially slow in a post-Meltdown/Spectre world? I know that Linux has semi-recently added kTLS and KSMBD to speed up TLS/SMB, and Windows used to implement parts of font rendering and its HTTP server in kernel mode to speed things up too, so this gave me the impression that having more things inside the kernel (== more monolithic) is better for speed. Or is this only the case because of how the Linux/NT kernels are implemented, and doesn't apply to microkernels?
- upboundspiral 10mo ago
  I am far from an expert on this topic, but I think you are right in pointing out that Spectre/Meltdown have greater impact on microkernel designs. I do think there is very interesting research in this topic however, on how systems could mitigate some of these attacks in a more foolproof way. https://microkerneldude.org/2024/04/18/gofetch-will-people-ever-learn/ https://microkerneldude.org/2024/04/18/gofetch-will-people-e... https://trustworthy.systems/publications/abstracts/Wistoff_SGBH_21.abstract https://trustworthy.systems/publications/abstracts/Wistoff_S...

gucci-on-fleek 10mo ago

> The idea that microkernels are slow came from analyzing a popular microkernel at the time - mach. It in no way is a true blanket statement for all microkernels. Don't microkernels inherently require lots of context switches between kernel-space and user-space, which are especially slow in a post-Meltdown/Spectre world? I know that Linux has semi-recently added kTLS and KSMBD to speed up TLS/SMB, and Windows used to implement parts of font rendering and its HTTP server in kernel mode to speed things up too, so this gave me the impression that having more things inside the kernel (== more monolithic) is better for speed. Or is this only the case because of how the Linux/NT kernels are implemented, and doesn't apply to microkernels?

upboundspiral 10mo ago
I am far from an expert on this topic, but I think you are right in pointing out that Spectre/Meltdown have greater impact on microkernel designs. I do think there is very interesting research in this topic however, on how systems could mitigate some of these attacks in a more foolproof way. https://microkerneldude.org/2024/04/18/gofetch-will-people-ever-learn/ https://microkerneldude.org/2024/04/18/gofetch-will-people-e... https://trustworthy.systems/publications/abstracts/Wistoff_SGBH_21.abstract https://trustworthy.systems/publications/abstracts/Wistoff_S...