Before we learned how to make them fast, perhaps. They do now tend to be very fast[0][1].
>One of the reasons for this could be high context switch latency.
As multiserver systems pass a lot of messages around, the important metric is IPC cost. Liedtke demonstrated microkernels do not have to be slow, with L3 and later L4. Liedtke's findings have endured fairly well[2] through time. It helps to know that seL4[3] has an order of magnitude faster IPC relative to Linux.
You'd need it to do a lot (think thousands of times) more IPC for the aggregated IPC to be slower than Linux.
>So I was thinking what could be done here.
I don't have a link at hand, but there's some involvement and synergy between seL4 team and RISC-V. I am hopeful it is enough to prevent the bad scenario where RISC-V is overoptimized for the now obsolete UNIX design, and a bad fit to contemporary OS architectures.
Before we learned how to make them fast, perhaps. They do now tend to be very fast[0][1].
>One of the reasons for this could be high context switch latency.
As multiserver systems pass a lot of messages around, the important metric is IPC cost. Liedtke demonstrated microkernels do not have to be slow, with L3 and later L4. Liedtke's findings have endured fairly well[2] through time. It helps to know that seL4[3] has an order of magnitude faster IPC relative to Linux.
You'd need it to do a lot (think thousands of times) more IPC for the aggregated IPC to be slower than Linux.
>So I was thinking what could be done here.
I don't have a link at hand, but there's some involvement and synergy between seL4 team and RISC-V. I am hopeful it is enough to prevent the bad scenario where RISC-V is overoptimized for the now obsolete UNIX design, and a bad fit to contemporary OS architectures.
0. https://blog.darknedgy.net/technology/2016/01/01/0/
1. https://news.ycombinator.com/item?id=10824382
2. https://sigops.org/s/conferences/sosp/2013/papers/p133-elphi...
3. https://sel4.systems/About/seL4-whitepaper.pdf