5 ms·

Let me try to offer a slightly more substantial comment than the others here so far. This proposal is motivated by trying to get more applications running off

by btrask 9y ago

Let me try to offer a slightly more substantial comment than the others here so far. This proposal is motivated by trying to get more applications running off the shelf or with minimal changes, which is a worthy goal. But to achieve that, it seems like the concept of a unikernel is growing more and more complexity. At some point, isn't it just Linux (or any other traditional kernel/OS) with a (slightly?) more modular design, statically linked applications, and no memory protection or scheduler (but it might even have that)? Wasn't the point of a unikernel to be small and simple? Aren't we losing something by bringing the kitchen sink back (even if there's a compile time option to turn it off)? And even once you have all that complexity, you still can't SSH in and diagnose problems, poke around, etc. I like the idea of unikernels, but I feel like they still haven't found their calling.

yazaddaruvala 9y ago
There are two things. 1. A Unikernel: It is supposed to be small and simple. Only containing the components it needs. And the security model is custom for the application itself. 2. A frame work to build Unikernels. This might include multiple implementations of file systems, schedulers, network stack, etc. The framework does need to be extensive (large) in order to give Unikernel developers the most ergonomics/reuse while developing. However, each Unikernel would be "small" as you describe. Hope that helps.
- btrask 9y ago
  Thanks. Yes, I understand. But if you started with (e.g.) Linux, and turned off all of the compile-time features that you could, isn't the end result very similar? Say you run your application as PID 1, etc., etc. My point is that a fully "generalized" unikernel is actually almost the same as a standard monolithic kernel. The technical differences are 1. memory protection, 2. scheduler (maybe), 3. single binary? 4. different and less flexible tooling around runtime debugging/admin. I mean, we all want a fully featured unikernel that boots instantly, consumes no memory, etc. But there's no reason to believe that a unikernel with all of the features necessary to run, say, a database, won't have overhead similar to Linux tuned for that same role. (Not trying to worship Linux here, I'm just holding it up as an example that has had a lot of eyeballs over the years.)
  - pentelian 9y ago
    It is hard to understand the benefit of a unikernel versus a very stripped down Linux kernel. If any people from the mentioned project are here, I'd love to hear your answer to this.
    - eximius 9y ago
      There may be some, but even if there isn't, some benefit could be the ease in which you strip it down.
    - lkurusa 9y ago
      There's a lot of literature that point towards more application-specific optimization in the lowest levels of the operating system, for example the Exokernel papers are an early example of this. More recently, you may want to have a look at the the MirageOS paper(s).
    - weberc2 9y ago
      Here's my bit of uninformed speculation: presumably a lot more potential for aggressive optimizations. It's unlikely that you can make Linux as bare-bones as you could a unikernel. Besides, for all intents and purposes, you can't run Linux through a whole-program optimizer along with your application (not sure if this is even a worthwhile objective). I would also think that communicating between the application and the "kernel" via function calls instead of system calls would yield some non-negligible performance gains as well.
  - jdboyd 9y ago
    If you strip Linux and run your app as PID 1, you will still have context switching between user space and kernel space, which can be fairly expensive (thus the interest in user land TCP/IP stacks). Presumably most unikernels avoid that cost.
    - minipci1321 9y ago
      You should clarify your terminology: -- "context switch" (expensive) is the switch among active (running on this CPU) tasks/threads/processes. -- switching between kernel and userspace would be "mode switch", much less expensive and of "constant" cost (see, for example, http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-ma...). Your phrase already carries this contradiction: "__can__ be fairly expensive" points to something depending on what is being executed, rather than a property of the mode switch itself. Then, arguably, the same need of that costly execution should also be present with unikernels?
yjftsjthsd-h 9y ago
If we get real benefits from disabling ex. memory protection, could we just use a deliberately crippled kernel from Linux/BSD? (rump kernels come to mind)
justicezyx 9y ago
Technology is all like this. A grant vision. A winding path. It's indispensable to address the migration problem. The idea that people would rewrite applications for someone's fancy new idea is not only stupid, it's actually never happened.

by btrask 9y ago

yazaddaruvala 9y ago

There are two things. 1. A Unikernel: It is supposed to be small and simple. Only containing the components it needs. And the security model is custom for the application itself. 2. A frame work to build Unikernels. This might include multiple implementations of file systems, schedulers, network stack, etc. The framework does need to be extensive (large) in order to give Unikernel developers the most ergonomics/reuse while developing. However, each Unikernel would be "small" as you describe. Hope that helps.

btrask 9y ago
Thanks. Yes, I understand. But if you started with (e.g.) Linux, and turned off all of the compile-time features that you could, isn't the end result very similar? Say you run your application as PID 1, etc., etc. My point is that a fully "generalized" unikernel is actually almost the same as a standard monolithic kernel. The technical differences are 1. memory protection, 2. scheduler (maybe), 3. single binary? 4. different and less flexible tooling around runtime debugging/admin. I mean, we all want a fully featured unikernel that boots instantly, consumes no memory, etc. But there's no reason to believe that a unikernel with all of the features necessary to run, say, a database, won't have overhead similar to Linux tuned for that same role. (Not trying to worship Linux here, I'm just holding it up as an example that has had a lot of eyeballs over the years.)
- pentelian 9y ago
  It is hard to understand the benefit of a unikernel versus a very stripped down Linux kernel. If any people from the mentioned project are here, I'd love to hear your answer to this.
  - eximius 9y ago
    There may be some, but even if there isn't, some benefit could be the ease in which you strip it down.
  - lkurusa 9y ago
    There's a lot of literature that point towards more application-specific optimization in the lowest levels of the operating system, for example the Exokernel papers are an early example of this. More recently, you may want to have a look at the the MirageOS paper(s).
  - weberc2 9y ago
    Here's my bit of uninformed speculation: presumably a lot more potential for aggressive optimizations. It's unlikely that you can make Linux as bare-bones as you could a unikernel. Besides, for all intents and purposes, you can't run Linux through a whole-program optimizer along with your application (not sure if this is even a worthwhile objective). I would also think that communicating between the application and the "kernel" via function calls instead of system calls would yield some non-negligible performance gains as well.
- jdboyd 9y ago
  If you strip Linux and run your app as PID 1, you will still have context switching between user space and kernel space, which can be fairly expensive (thus the interest in user land TCP/IP stacks). Presumably most unikernels avoid that cost.
  - minipci1321 9y ago
    You should clarify your terminology: -- "context switch" (expensive) is the switch among active (running on this CPU) tasks/threads/processes. -- switching between kernel and userspace would be "mode switch", much less expensive and of "constant" cost (see, for example, http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-ma...). Your phrase already carries this contradiction: "__can__ be fairly expensive" points to something depending on what is being executed, rather than a property of the mode switch itself. Then, arguably, the same need of that costly execution should also be present with unikernels?

yjftsjthsd-h 9y ago

If we get real benefits from disabling ex. memory protection, could we just use a deliberately crippled kernel from Linux/BSD? (rump kernels come to mind)

justicezyx 9y ago

Technology is all like this. A grant vision. A winding path. It's indispensable to address the migration problem. The idea that people would rewrite applications for someone's fancy new idea is not only stupid, it's actually never happened.