17 ms·

"While early microkernel work saw significant performanceoverheads attributed to inter-process communication (IPC)and address space changes [15,16,20], such ove

"While early microkernel work saw significant performanceoverheads attributed to inter-process communication (IPC)and address space changes [15,16,20], such overheads areless significant today. Compared to the uniprocessor systemsof the 80s and 90s, today’s servers contain dozens of cores,which allows microkernel invocation to leverage inter-coreIPC while maintaining application cache locality. This ap-proach can evenimproveoverall performance when there islittle state to communicate across the IPC (common in zero-copy networking) and in avoiding ring switch costs of systemcalls. Moreover, recent security vulnerabilities such as Melt-down [43] force kernel/user address space isolation, even inmonolithic kernels [25]. Techniques like tagged-TLB supportin modern processors, streamlined ring switching hardwaremade necessary with the resurgence of virtualization, andIPC optimization techniques such as those explored in theL4 microkernel [29], in FlexSC [58], and in SkyBridge [44],further allow a modern microkernel to essentially close theperformance gap between direct system calls and indirectsystem calls through IPC."

snvzz 7y ago
You're right to quote some text that addresses the idea that "microkernels are slow", which keeps popping up. To that, I add this article[0], which is sufficient in destroying that idea. [0]https://blog.darknedgy.net/technology/2016/01/01/0/ https://blog.darknedgy.net/technology/2016/01/01/0/
- AlphaSite 7y ago
  Another point is that macOS and iOS are moving towards a user space driver stack and away from Kernel space.
  - snvzz 7y ago
    Because, save few exceptions (e.g. timers, early debug serial...) running drivers in supervisor mode isn't very smart. Drivers tend to have high bug density, and supervisor mode means high potential for damage. Much can be mitigated by running drivers in userspace[0][1], especially with some IOMMU help. [0] https://www.cs.vu.nl/~herbertb/papers/minix3_dsn09.pdf https://www.cs.vu.nl/~herbertb/papers/minix3_dsn09.pdf [1] https://wiki.minix3.org/doku.php?id=www:documentation:reliability https://wiki.minix3.org/doku.php?id=www:documentation:reliab...
  - pjmlp 7y ago
    Android and Windows as well.
    - panpanna 7y ago
      Linux has been moving towards hybrid drivers for certain components for a while now. I think you can run large parts of the filesystem and network stack in user-land now.
      - pjmlp 7y ago
        There is a big difference is that the other OSes are doing it no matter how many pitchforks come into their way, while with Linux you need to find a security conscious distribution.
        Matthias247 7y ago
        I think it’s hard to say that without knowing what’s going on in that companies and how many internal disagreements had been there. And even if Apple now talks about user-Mode drivers - do we even know what percentage they aim for?
        pjmlp 7y ago
        Yes we do, as they presented at WWDC, all of them. They are following a two release steps, in release N, the user space drivers for a specific class get introduced and the respective kernel APIs are automatically deprecated. In release N + 1, those deprecated APIs will be removed.
- BurningCycles 7y ago
  I disagree, these are VERY old papers (~30 years old) of comparisons containing very little data from what I can see at a quick glance. I saw a talk a couple of years ago by Tanenbaum where he said he would be ok with Minix being 20% slower than a monolithic kernel like Linux, indicating that it was currently slower than that. Granted, Minix has not seen the type of optimizations that popular monolithic kernel has due to lack of manpower. So, I really look forward to seeing benchmarks made between monolithic kernels and new micro kernels like Google's Zircon, and Redox once they've had sufficient time to mature.
  - naasking 7y ago
    > Tanenbaum where he said he would be ok with Minix being 20% slower than a monolithic kernel like Linux, indicating that it was currently slower than that. It doesn't indicate anything of the sort. He was making a comment that the reliability and security benefits of microkernels are simply more important than performance in this mind.
  - gnufx 7y ago
    They may be old, but what major advances in monolithic kernels have there been to invalidate them now? There seem to have been significant advances in microkernels. (I was glad to have been using fast microkernel-ish systems daily in the 1980s, and not VAX/VMS.)
    - BurningCycles 7y ago
      >but what major advances in monolithic kernels have there been to invalidate them now? What are the significant advances in micro kernels that does not apply to monolithic kernels ? Also they are not only VERY old, they seem intentionally vague when it comes to actual data about the systems they are comparing against. In short, I welcome the new micro kernels so that we can see a comparison between modern monolithic and modern micro kernels and actually get a good representation of what the performance difference is. Because if not for performance, there is no reason not to use a micro kernel.
      - 7y ago
- zaarn 7y ago
  IPC is a tad slower than not IPC. However, stuff like WebAssembly and other sandboxing methods can be used to leverage two processes into the same address space. Your filesystem driver then simply lives as a module in address space and it's a normal process. The IPC turns into a simple jump using a pointer value provided by the kernel (which depending on the trust level can provide parameter validation or can be a plain pointer to the correct function).
  - hvidgaard 7y ago
    How would that work? The entire premise of Microkernels is that everything runs in a dedicated processes such that if one crashes, the system can continue all other processes and only need to recover that single process. The cost of switching processes are not a problem of address space, the MMU makes sure that is not a problem as shared memory is a reasonable tradeoff for certain domains where performance is necessary. Normally you'd rather want use messages but that is a different topic. In either case, the cost of a process switch is handling the registers and cache - that will not go away no matter how you do it, which is why multicore implementation with messages can actually turn out being faster. Less switching and more locality.
    - zaarn 7y ago
      Well, with webassembly the process can run under ring0 but still be isolated as if it was running in ring3. The crash mechanism isn't different; if the driver crashes then the kernel can kill it and deallocate it's resources, a device manager process can then restart the driver. The advantage is that you can include small, audited and verified binaries that can run code as ring 0 to remove abstraction from accessing the raw hardware. The cost of switching processes is significantly reduced when you don't need to switch privilege levels and not having to invalidate the TLB as well as not having to change address space at all will make a context switch not significantly more expensive than a function call. You get compile-time isolation and can still take advantage of the MMU when needed. And using such an implementation does not prevent you from implementing your driver such that it can run on each core and take advantage of it or even passes messages. An ethernet driver could still, for example, pass a message when the "send data to tcp socket" function is called while allowing another program to use the same function without any message passing, depending on what is better for your use case.
- jacquesm 7y ago
  It always was a lot less important than proponents of monolithic kernels made it seem, there were two things that were left out of such discussions: - paging is a very efficient way to copy a block of data from one process to another. - the perceived speed of an interactive system has everything to do with responsiveness and very little with actual throughput. And responsiveness is associated with near real-time operation which happens to be something micro kernel based systems excel at.
  - zzzcpan 7y ago
    With the advent of multi core CPUs monolithic kernels jumping in on doing slow shared memory concurrency kind of killed the idea of monolithic kernels to be fast. They can't be fast unless they do actor model, but it goes against the idea of monoliths, hence they can't do better than microkernels.

snvzz 7y ago

You're right to quote some text that addresses the idea that "microkernels are slow", which keeps popping up. To that, I add this article[0], which is sufficient in destroying that idea. [0]https://blog.darknedgy.net/technology/2016/01/01/0/ https://blog.darknedgy.net/technology/2016/01/01/0/

AlphaSite 7y ago
Another point is that macOS and iOS are moving towards a user space driver stack and away from Kernel space.
- snvzz 7y ago
  Because, save few exceptions (e.g. timers, early debug serial...) running drivers in supervisor mode isn't very smart. Drivers tend to have high bug density, and supervisor mode means high potential for damage. Much can be mitigated by running drivers in userspace[0][1], especially with some IOMMU help. [0] https://www.cs.vu.nl/~herbertb/papers/minix3_dsn09.pdf https://www.cs.vu.nl/~herbertb/papers/minix3_dsn09.pdf [1] https://wiki.minix3.org/doku.php?id=www:documentation:reliability https://wiki.minix3.org/doku.php?id=www:documentation:reliab...
- pjmlp 7y ago
  Android and Windows as well.
  - panpanna 7y ago
    Linux has been moving towards hybrid drivers for certain components for a while now. I think you can run large parts of the filesystem and network stack in user-land now.
    - pjmlp 7y ago
      There is a big difference is that the other OSes are doing it no matter how many pitchforks come into their way, while with Linux you need to find a security conscious distribution.
      - Matthias247 7y ago
        I think it’s hard to say that without knowing what’s going on in that companies and how many internal disagreements had been there. And even if Apple now talks about user-Mode drivers - do we even know what percentage they aim for?
        pjmlp 7y ago
        Yes we do, as they presented at WWDC, all of them. They are following a two release steps, in release N, the user space drivers for a specific class get introduced and the respective kernel APIs are automatically deprecated. In release N + 1, those deprecated APIs will be removed.
BurningCycles 7y ago
I disagree, these are VERY old papers (~30 years old) of comparisons containing very little data from what I can see at a quick glance. I saw a talk a couple of years ago by Tanenbaum where he said he would be ok with Minix being 20% slower than a monolithic kernel like Linux, indicating that it was currently slower than that. Granted, Minix has not seen the type of optimizations that popular monolithic kernel has due to lack of manpower. So, I really look forward to seeing benchmarks made between monolithic kernels and new micro kernels like Google's Zircon, and Redox once they've had sufficient time to mature.
- naasking 7y ago
  > Tanenbaum where he said he would be ok with Minix being 20% slower than a monolithic kernel like Linux, indicating that it was currently slower than that. It doesn't indicate anything of the sort. He was making a comment that the reliability and security benefits of microkernels are simply more important than performance in this mind.
- gnufx 7y ago
  They may be old, but what major advances in monolithic kernels have there been to invalidate them now? There seem to have been significant advances in microkernels. (I was glad to have been using fast microkernel-ish systems daily in the 1980s, and not VAX/VMS.)
  - BurningCycles 7y ago
    >but what major advances in monolithic kernels have there been to invalidate them now? What are the significant advances in micro kernels that does not apply to monolithic kernels ? Also they are not only VERY old, they seem intentionally vague when it comes to actual data about the systems they are comparing against. In short, I welcome the new micro kernels so that we can see a comparison between modern monolithic and modern micro kernels and actually get a good representation of what the performance difference is. Because if not for performance, there is no reason not to use a micro kernel.
    - 7y ago
zaarn 7y ago
IPC is a tad slower than not IPC. However, stuff like WebAssembly and other sandboxing methods can be used to leverage two processes into the same address space. Your filesystem driver then simply lives as a module in address space and it's a normal process. The IPC turns into a simple jump using a pointer value provided by the kernel (which depending on the trust level can provide parameter validation or can be a plain pointer to the correct function).
- hvidgaard 7y ago
  How would that work? The entire premise of Microkernels is that everything runs in a dedicated processes such that if one crashes, the system can continue all other processes and only need to recover that single process. The cost of switching processes are not a problem of address space, the MMU makes sure that is not a problem as shared memory is a reasonable tradeoff for certain domains where performance is necessary. Normally you'd rather want use messages but that is a different topic. In either case, the cost of a process switch is handling the registers and cache - that will not go away no matter how you do it, which is why multicore implementation with messages can actually turn out being faster. Less switching and more locality.
  - zaarn 7y ago
    Well, with webassembly the process can run under ring0 but still be isolated as if it was running in ring3. The crash mechanism isn't different; if the driver crashes then the kernel can kill it and deallocate it's resources, a device manager process can then restart the driver. The advantage is that you can include small, audited and verified binaries that can run code as ring 0 to remove abstraction from accessing the raw hardware. The cost of switching processes is significantly reduced when you don't need to switch privilege levels and not having to invalidate the TLB as well as not having to change address space at all will make a context switch not significantly more expensive than a function call. You get compile-time isolation and can still take advantage of the MMU when needed. And using such an implementation does not prevent you from implementing your driver such that it can run on each core and take advantage of it or even passes messages. An ethernet driver could still, for example, pass a message when the "send data to tcp socket" function is called while allowing another program to use the same function without any message passing, depending on what is better for your use case.
jacquesm 7y ago
It always was a lot less important than proponents of monolithic kernels made it seem, there were two things that were left out of such discussions: - paging is a very efficient way to copy a block of data from one process to another. - the perceived speed of an interactive system has everything to do with responsiveness and very little with actual throughput. And responsiveness is associated with near real-time operation which happens to be something micro kernel based systems excel at.
- zzzcpan 7y ago
  With the advent of multi core CPUs monolithic kernels jumping in on doing slow shared memory concurrency kind of killed the idea of monolithic kernels to be fast. They can't be fast unless they do actor model, but it goes against the idea of monoliths, hence they can't do better than microkernels.