3 ms·

Here I was, ready to rail against this horrific explosion in software complexity, and then you go and say realize gains of up to 10x in performance (based on t

Here I was, ready to rail against this horrific explosion in software complexity, and then you go and say realize gains of up to 10x in performance (based on the original MIT exokernel papers) Is that true? Do the observed improvements in the field get anywhere close to that theoretical boost? If that's true, then that's incredible. Which layer of the OS is responsible for an Nx slowdown? Where N is whatever the real multiplier actually is most of the time. (Aside: it's probably not a good idea to imply "high level language == doesn't use fork." Fork is a fundamental primitive. There are things you can do by forking which you can't do by other means. I mean "can't" in the same say as "yes, every language is turing complete and so therefore can simulate any other language, but you can't write recursion in BASIC, because you wouldn't want to try.")

jpgvm 11y ago
Fork is not a language feature though, it's an operating system feature. It just so happens that it feels that way because it's so universal in multi-process systems. The reality is that there are many uni-process systems, like embedded microcontrollers etc. Unikernels actually have a lot in common with these sorts of environments. For instance if you are running a unikernel on PV Xen or KVM you have direct access to the paravirtualized network and block device buffers, avoiding additional context switches when doing IO (this is where those 10x speedups from from). Thing is though you can achieve the same performance on more traditional OS + multi-process setups too but it does require some level of device level virtualisation + isolation and kernel bypass. For instance combining PCI SRIOV with say PF_RING would give you effectively the same performance profile without sacrificing OS level features.
nostrademons 11y ago
Here's the original MIT research group. Consider that this was done 17 years ago, so it's possible that relative performance differences are very different: https://pdos.csail.mit.edu/exo.html https://pdos.csail.mit.edu/exo.html The speedup they observed was because they could bypass all the layers of the OS and implement abstractions specialized to their particular use-case, making use of information that is available to the application but not to the kernel when deciding how to allocate resources. For example, Cheetah stored preformatted IP packets on disk, which would be sent straight out to the NIC along with the file contents from the filesystem cache. There was no need for the overhead of a TCP/IP stack, no need for buffer copies between kernel and user mode, no need for scheduler overhead as the process is put on the wait queue while waiting for the filesystem, no need for kernel-mode context switches. I could imagine several similar cases with modern apps, particularly as the NUMA penalty has grown and we've gotten hardware technologies like RDMA. Imagine a Node.js implementation with a locality-aware scheduler, for example: instead of running whichever closure is attached to the file descriptor that epoll happens to return, it preferentially executes the closure that was most recently enqueued, on the theory that all of its context is likely to be hot in cache. Or imagine memcached with full control over the TLB, so that you could lock certain entries (eg. active session objects) into the TLB and never page fault on them.
andrewstuart 11y ago
We carried out some simple tests of Nginx on the rump kernel a few months ago. Performance is approximately similar to running on an "ordinary" operating system +/- 10% depending on a variety of factors.
- avsm 11y ago
  It's worth bearing in mind that the Rump Xen backend isn't well optimised at the moment, so there's quite a bit of low hanging fruit that could probably boost performance quite a lot. I think things like multi-page netfront, more careful rx/tx batching, and probably scheduler measurements will have an impact. The focus right now is on getting the individual applications to run reliably and robustly as unikernels when recompiled under Rump, and upstreaming patches where applicable.
  - deleted 11y ago
    [deleted]

jpgvm 11y ago

Fork is not a language feature though, it's an operating system feature. It just so happens that it feels that way because it's so universal in multi-process systems. The reality is that there are many uni-process systems, like embedded microcontrollers etc. Unikernels actually have a lot in common with these sorts of environments. For instance if you are running a unikernel on PV Xen or KVM you have direct access to the paravirtualized network and block device buffers, avoiding additional context switches when doing IO (this is where those 10x speedups from from). Thing is though you can achieve the same performance on more traditional OS + multi-process setups too but it does require some level of device level virtualisation + isolation and kernel bypass. For instance combining PCI SRIOV with say PF_RING would give you effectively the same performance profile without sacrificing OS level features.

nostrademons 11y ago

Here's the original MIT research group. Consider that this was done 17 years ago, so it's possible that relative performance differences are very different: https://pdos.csail.mit.edu/exo.html https://pdos.csail.mit.edu/exo.html The speedup they observed was because they could bypass all the layers of the OS and implement abstractions specialized to their particular use-case, making use of information that is available to the application but not to the kernel when deciding how to allocate resources. For example, Cheetah stored preformatted IP packets on disk, which would be sent straight out to the NIC along with the file contents from the filesystem cache. There was no need for the overhead of a TCP/IP stack, no need for buffer copies between kernel and user mode, no need for scheduler overhead as the process is put on the wait queue while waiting for the filesystem, no need for kernel-mode context switches. I could imagine several similar cases with modern apps, particularly as the NUMA penalty has grown and we've gotten hardware technologies like RDMA. Imagine a Node.js implementation with a locality-aware scheduler, for example: instead of running whichever closure is attached to the file descriptor that epoll happens to return, it preferentially executes the closure that was most recently enqueued, on the theory that all of its context is likely to be hot in cache. Or imagine memcached with full control over the TLB, so that you could lock certain entries (eg. active session objects) into the TLB and never page fault on them.

andrewstuart 11y ago

We carried out some simple tests of Nginx on the rump kernel a few months ago. Performance is approximately similar to running on an "ordinary" operating system +/- 10% depending on a variety of factors.

avsm 11y ago
It's worth bearing in mind that the Rump Xen backend isn't well optimised at the moment, so there's quite a bit of low hanging fruit that could probably boost performance quite a lot. I think things like multi-page netfront, more careful rx/tx batching, and probably scheduler measurements will have an impact. The focus right now is on getting the individual applications to run reliably and robustly as unikernels when recompiled under Rump, and upstreaming patches where applicable.
- deleted 11y ago
  [deleted]