6 ms·

Is the assumption here that scheduling, drivers, resource management etc. will all be on par with or better than full-fledged operating systems? Seems like what

Is the assumption here that scheduling, drivers, resource management etc. will all be on par with or better than full-fledged operating systems? Seems like what you might gain in being closer to the metal could easily be lost by wheels that have already been invented.

nostrademons 11y ago
I suspect it's that you won't need most of them in a typical application. The idea behind unikernels is that now that we have pervasive virtualization, most virtual machines are running only a single application anyway. So you have an instance type for memcached, one for postgres, one for Node, one for nginx, one for Redis, one for your JVM, etc. In many cases, these apps already include user-level scheduling and resource management, which often works at cross purposes with the OS. In other cases, they could run much faster if they implemented these specialized to their particular workload, and didn't need to run through an OS scheduler that also needs to support responsive desktop apps.
- sillysaurus3 11y ago
  The reason this is a bad idea is because it restricts your ability to redesign a system. If you want to add another program, you can't do it by definition. Though I suppose the solution in that scenario is "Take it out of the unikernel, then." Still, if you rip out the fundamental abstractions of an OS, how would you run an application that relies on e.g. fork? Or any application that runs a shell command in any way? My understanding is probably falling short. I should read up more on unikernels.
  - detaro 11y ago
    > Still, if you rip out the fundamental abstractions of an OS, how would you run an application that relies on e.g. fork? Or any application that runs a shell command in any way? You probably don't (at least not without removing/changing that part of the application). Unikernels explicitly do not aim at allowing to run a random preexisting application and trade that for the freedom from existing APIs and conventions.
  - nostrademons 11y ago
    No, the solution in that scenario is "Spin up another VM, and talk to it over socket." That VM could be another unikernel server, or it could be vanilla Linux that you talk to over sshd, Fabric, Puppet, whatever. It's important to understand the context behind the current unikernel hype: it assumes that you've embraced cloud providers (or at least run your own cloud on Xen or kvm), it assumes that you are building a distributed system, and it assumes your distributed system is built using standardized components. If 99% of software is various combinations of nginx, Node, Python, Ruby, the JVM, memcached, redis, PostGres, MySQL, and MongoDB, it can make sense to modify just those 10 applications to run on bare metal, cut Linux out of it entirely, realize gains of up to 10x in performance (based on the original MIT exokernel papers), and still present the same programming interface to application-level programmers. Unikernels are not useful to people who just want to hack C on a single box, nor are they useful to giant companies like Google where all of their software is written in C++ with POSIX APIs. But they could save a lot of money for many mid-range businesses who currently host on AWS or GCE and write largely in high-level languages.
    - sillysaurus3 11y ago
      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.
jandrewrogers 11y ago
Bypassing the operating system and implementing this functionality in user space is already common practice in high-performance server software. From the perspective of a specific server workload, it is pretty easy to design purpose-built schedulers and resource managers that will greatly outperform the ones in your operating system. There is much room to invent better wheels. I presume this software is designed to make that easier, since there are fewer operating system quirks to work around. Obviously this is not suitable for every programmer (e.g. if you have difficulty designing software that does not leak memory, this is not for you) but there is a subset that can design correct schedulers and robust resource managers in their sleep. The integer factor improvements in system throughput make it a worthwhile optimization if you know how to do it.

nostrademons 11y ago

I suspect it's that you won't need most of them in a typical application. The idea behind unikernels is that now that we have pervasive virtualization, most virtual machines are running only a single application anyway. So you have an instance type for memcached, one for postgres, one for Node, one for nginx, one for Redis, one for your JVM, etc. In many cases, these apps already include user-level scheduling and resource management, which often works at cross purposes with the OS. In other cases, they could run much faster if they implemented these specialized to their particular workload, and didn't need to run through an OS scheduler that also needs to support responsive desktop apps.

sillysaurus3 11y ago
The reason this is a bad idea is because it restricts your ability to redesign a system. If you want to add another program, you can't do it by definition. Though I suppose the solution in that scenario is "Take it out of the unikernel, then." Still, if you rip out the fundamental abstractions of an OS, how would you run an application that relies on e.g. fork? Or any application that runs a shell command in any way? My understanding is probably falling short. I should read up more on unikernels.
- detaro 11y ago
  > Still, if you rip out the fundamental abstractions of an OS, how would you run an application that relies on e.g. fork? Or any application that runs a shell command in any way? You probably don't (at least not without removing/changing that part of the application). Unikernels explicitly do not aim at allowing to run a random preexisting application and trade that for the freedom from existing APIs and conventions.
- nostrademons 11y ago
  No, the solution in that scenario is "Spin up another VM, and talk to it over socket." That VM could be another unikernel server, or it could be vanilla Linux that you talk to over sshd, Fabric, Puppet, whatever. It's important to understand the context behind the current unikernel hype: it assumes that you've embraced cloud providers (or at least run your own cloud on Xen or kvm), it assumes that you are building a distributed system, and it assumes your distributed system is built using standardized components. If 99% of software is various combinations of nginx, Node, Python, Ruby, the JVM, memcached, redis, PostGres, MySQL, and MongoDB, it can make sense to modify just those 10 applications to run on bare metal, cut Linux out of it entirely, realize gains of up to 10x in performance (based on the original MIT exokernel papers), and still present the same programming interface to application-level programmers. Unikernels are not useful to people who just want to hack C on a single box, nor are they useful to giant companies like Google where all of their software is written in C++ with POSIX APIs. But they could save a lot of money for many mid-range businesses who currently host on AWS or GCE and write largely in high-level languages.
  - sillysaurus3 11y ago
    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.

jandrewrogers 11y ago

Bypassing the operating system and implementing this functionality in user space is already common practice in high-performance server software. From the perspective of a specific server workload, it is pretty easy to design purpose-built schedulers and resource managers that will greatly outperform the ones in your operating system. There is much room to invent better wheels. I presume this software is designed to make that easier, since there are fewer operating system quirks to work around. Obviously this is not suitable for every programmer (e.g. if you have difficulty designing software that does not leak memory, this is not for you) but there is a subset that can design correct schedulers and robust resource managers in their sleep. The integer factor improvements in system throughput make it a worthwhile optimization if you know how to do it.