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.)

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.

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-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?

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.

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).

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.

There may be some, but even if there isn't, some benefit could be the ease in which you strip it down.