5 ms·

Presenting services in user space has always been a benefit of microkernels, which is welcomed considering that I frequently make use of FUSE or OpenVPN. The o

by barosl 12y ago

Presenting services in user space has always been a benefit of microkernels, which is welcomed considering that I frequently make use of FUSE or OpenVPN. The only concern for me is performance. Though I believe the service server provided by the Hurd would outperform FUSE, I'm not sure that it is worth the overhead of all other parts in the entire system. If the performance decrease is negligible, I'll be happy to use the kernel.

pjmlp 12y ago
The performance history is old news. QNX, Symbian, L4, PikeOS are just some examples of operating systems with micro-kernels that achieved success on the market. Only the desktop/server OSs still lag behind due to compatibility with existing software.
- LnxPrgr3 12y ago
  Have they worked out how to improve performance, or have they succeeded in spite of it? I run software that (thanks to poor design, IMO) manages to bottleneck context switching on Linux's monolithic kernel. I can't imagine this not being worse with more of the OS pushed out into userspace, though I'd love to be proven wrong!
  - lucian1900 12y ago
    Kernels in the L4 [1] family are effectively designed to reduce the overhead of calls across process boundaries, to the extent that software is unlikely to behave any differently from a kernel like Linux. It can potentially be even better, since you can potentially get more direct access to whatever resource you're contending on. 1. http://en.wikipedia.org/wiki/L4_microkernel_family http://en.wikipedia.org/wiki/L4_microkernel_family
  - jckt 12y ago
    According to this paper[1] about L4, it seems to be the former (that is, performance has genuinely improved). [1]http://www.nicta.com.au/pub?doc=6930 http://www.nicta.com.au/pub?doc=6930
  - Rusky 12y ago
    L4 was a big push to improve microkernel performance. It's improved to the point that it only costs a few percent throughput, which means context switching itself on L4 is much faster than on Linux. The Mill CPU design doesn't have a user/kernel mode split, and it's also single-address-space (still with the same level of protection, just a different mechanism). Protection domain switching is done through portal calls, which are essentially shared library-like indirect calls with metadata for the CPU. Further, saving and restoring things like registers is done asynchronously. That should remove any remaining performance difference (and make monolithic designs faster too).
    - SSLy 12y ago
      Where can I find more structured info about the mill cpu? Their www is basically empty.
      - Rusky 12y ago
        The vast majority of information available right now is in their videos: http://millcomputing.com/docs/ http://millcomputing.com/docs/ Their forum has some good responses from the team on follow up questions asked by the community as well.
- auvrw 12y ago
  except the hurd runs on mach... i read a bunch of the hurd documentation a couple of years ago, including the paper by the people who tried porting it to L4. i also tried installing the debian port on an old desktop but had some driver issues. i guess most people run it in a hypervisor. there are a lot of architectural advantages to putting all drivers in user space. the hurd isn't really totally comparable to plan 9 (because it runs on a microkernel) or minix (because it's thought of as being independent of the any partciular microkernel). but it seems like the community/political issues -- plus the amount of cruft that's bound to accumulate in a codebase that old -- has nearly slowed to project to a grinding halt, which is a kind of a shame.
noblethrasher 12y ago
Here's Andy Tannenbaum's response to the performance issues of microkernels: https://www.youtube.com/watch?v=bx3KuE7UjGA#t=2832 https://www.youtube.com/watch?v=bx3KuE7UjGA#t=2832 (should start at about 47:15)
- tormeh 12y ago
  Tl;dr: He thinks reliability trumps performance. I mean, he has a point, but then there's the reliability of the hardware, and any process can be made more reliable if you know the details of the the software instead of just trying to make everything about the system the software runs on reliable. I guess a reliable OS can be a middle ground between bespoke systems with redundant hardware and a single computer running Debian. Well, I guess a reliable OS is always a good thing, but it'll never be enough for everything.
  - pjmlp 12y ago
    I am with him. It was putting performance above reliability that has brought the industry to the current state of security exploits that cost millions in tooling, bug fixes and paying damages. We are still very far from other industries where reliability is taken seriously.
    - tormeh 12y ago
      Reliability and security are different things. Industrial controller manufacturers often don't give a shit about security, but their products are much more reliable than x86 running Linux.
      - pjmlp 12y ago
        I think otherwise. Reliability implies security.
    - taeric 12y ago
      This argument cuts both ways. The emphasis on performance and, you know, working is what led to the massive amount of money in the market. That is, yes there was a cost to this. However, leaving aside the unknowns of whether there would still be millions in tooling necessary for security even with microkernels, you have to provide some sort of reasonable argument that the current market (> billions) would still exist. You can't just take that for granted.
ChuckMcM 12y ago
In general, a kernel that requires a five transitions (user->kernel->user->kernel->user) for system service calls, will be less performant than one which requires only three (user->kernel->user) The impact is magnified with multiple services being involved. So if you naively design your disk driver as a user level process, your file system as a user level process, then something like read() from a user's applications goes: read -> kernel -> user(fs) -> kernel -> user(disk) -> kernel -> user(fs) -> kernel -> read(app). It was really really slow when things had different page mappings but it gets better if you have an alloc area where everyone shares the same virtual address space (keeps TLB thrashing down). Per another comment on this thread the Docker as P9 process is pretty close. But it doesn't share services per se across users in the space. Spring (Sun's research OS) looked at cutting the penalties down for moving kernel/user with some nice 'doors' kinds of things. At the time there was discussion that with enough address space (so that you're VM system got the benefit of warm caches and no page remapping) you could really do some interesting things. Were I retired I would probably spend some time playing with that stuff on a modern 64 bit architecture :-)
- wolfgke 12y ago
  five transitions (user->kernel->user->kernel->user) three (user->kernel->user) Aren't these 4 vs. 2 transitions?
  - ChuckMcM 12y ago
    You are correct 5 contexts, four transitions.
- rbanffy 12y ago
  > In general, a kernel that requires a five transitions I wonder if it couldn't be accelerated with hardware support...

by barosl 12y ago

pjmlp 12y ago

The performance history is old news. QNX, Symbian, L4, PikeOS are just some examples of operating systems with micro-kernels that achieved success on the market. Only the desktop/server OSs still lag behind due to compatibility with existing software.

LnxPrgr3 12y ago
Have they worked out how to improve performance, or have they succeeded in spite of it? I run software that (thanks to poor design, IMO) manages to bottleneck context switching on Linux's monolithic kernel. I can't imagine this not being worse with more of the OS pushed out into userspace, though I'd love to be proven wrong!
- lucian1900 12y ago
  Kernels in the L4 [1] family are effectively designed to reduce the overhead of calls across process boundaries, to the extent that software is unlikely to behave any differently from a kernel like Linux. It can potentially be even better, since you can potentially get more direct access to whatever resource you're contending on. 1. http://en.wikipedia.org/wiki/L4_microkernel_family http://en.wikipedia.org/wiki/L4_microkernel_family
- jckt 12y ago
  According to this paper[1] about L4, it seems to be the former (that is, performance has genuinely improved). [1]http://www.nicta.com.au/pub?doc=6930 http://www.nicta.com.au/pub?doc=6930
- Rusky 12y ago
  L4 was a big push to improve microkernel performance. It's improved to the point that it only costs a few percent throughput, which means context switching itself on L4 is much faster than on Linux. The Mill CPU design doesn't have a user/kernel mode split, and it's also single-address-space (still with the same level of protection, just a different mechanism). Protection domain switching is done through portal calls, which are essentially shared library-like indirect calls with metadata for the CPU. Further, saving and restoring things like registers is done asynchronously. That should remove any remaining performance difference (and make monolithic designs faster too).
  - SSLy 12y ago
    Where can I find more structured info about the mill cpu? Their www is basically empty.
    - Rusky 12y ago
      The vast majority of information available right now is in their videos: http://millcomputing.com/docs/ http://millcomputing.com/docs/ Their forum has some good responses from the team on follow up questions asked by the community as well.
auvrw 12y ago
except the hurd runs on mach... i read a bunch of the hurd documentation a couple of years ago, including the paper by the people who tried porting it to L4. i also tried installing the debian port on an old desktop but had some driver issues. i guess most people run it in a hypervisor. there are a lot of architectural advantages to putting all drivers in user space. the hurd isn't really totally comparable to plan 9 (because it runs on a microkernel) or minix (because it's thought of as being independent of the any partciular microkernel). but it seems like the community/political issues -- plus the amount of cruft that's bound to accumulate in a codebase that old -- has nearly slowed to project to a grinding halt, which is a kind of a shame.

noblethrasher 12y ago

Here's Andy Tannenbaum's response to the performance issues of microkernels: https://www.youtube.com/watch?v=bx3KuE7UjGA#t=2832 https://www.youtube.com/watch?v=bx3KuE7UjGA#t=2832 (should start at about 47:15)

tormeh 12y ago
Tl;dr: He thinks reliability trumps performance. I mean, he has a point, but then there's the reliability of the hardware, and any process can be made more reliable if you know the details of the the software instead of just trying to make everything about the system the software runs on reliable. I guess a reliable OS can be a middle ground between bespoke systems with redundant hardware and a single computer running Debian. Well, I guess a reliable OS is always a good thing, but it'll never be enough for everything.
- pjmlp 12y ago
  I am with him. It was putting performance above reliability that has brought the industry to the current state of security exploits that cost millions in tooling, bug fixes and paying damages. We are still very far from other industries where reliability is taken seriously.
  - tormeh 12y ago
    Reliability and security are different things. Industrial controller manufacturers often don't give a shit about security, but their products are much more reliable than x86 running Linux.
    - pjmlp 12y ago
      I think otherwise. Reliability implies security.
  - taeric 12y ago
    This argument cuts both ways. The emphasis on performance and, you know, working is what led to the massive amount of money in the market. That is, yes there was a cost to this. However, leaving aside the unknowns of whether there would still be millions in tooling necessary for security even with microkernels, you have to provide some sort of reasonable argument that the current market (> billions) would still exist. You can't just take that for granted.

ChuckMcM 12y ago

In general, a kernel that requires a five transitions (user->kernel->user->kernel->user) for system service calls, will be less performant than one which requires only three (user->kernel->user) The impact is magnified with multiple services being involved. So if you naively design your disk driver as a user level process, your file system as a user level process, then something like read() from a user's applications goes: read -> kernel -> user(fs) -> kernel -> user(disk) -> kernel -> user(fs) -> kernel -> read(app). It was really really slow when things had different page mappings but it gets better if you have an alloc area where everyone shares the same virtual address space (keeps TLB thrashing down). Per another comment on this thread the Docker as P9 process is pretty close. But it doesn't share services per se across users in the space. Spring (Sun's research OS) looked at cutting the penalties down for moving kernel/user with some nice 'doors' kinds of things. At the time there was discussion that with enough address space (so that you're VM system got the benefit of warm caches and no page remapping) you could really do some interesting things. Were I retired I would probably spend some time playing with that stuff on a modern 64 bit architecture :-)

wolfgke 12y ago
five transitions (user->kernel->user->kernel->user) three (user->kernel->user) Aren't these 4 vs. 2 transitions?
- ChuckMcM 12y ago
  You are correct 5 contexts, four transitions.
rbanffy 12y ago
> In general, a kernel that requires a five transitions I wonder if it couldn't be accelerated with hardware support...