On Fri, Sep 16, 2016 at 3:28 AM, Ian Eyberg <i...@deferpanic.com> wrote:

Hi All:
>   I gave a presentation last night at the ACCU meetup on the 'Current
> State of C++ Unikernels'. Dor happened to be around and mentioned that this
> list might be interested in seeing the slides I was presenting so here they
> are: https://speakerdeck.com/eyberg/the-current-state-of-c-
> plus-plus-unikernels - I don't know how many people showed up but I'm
> guessing there was somewhere around 40-50. Also - if you're in the Bay Area
> we have regular unikernel meetups and definitely are looking for more
> speakers - http://www.meetup.com/San-Francisco-Unikernels/ .
> - Ian
Thanks. Very interesting.

It seems that one of the places that OSv is outdone by the other unikernels
you surveyed is in its size.

This is partly to blame for the current approach of OSv to always include
the entire kitchen sink - the entire Posix, Linux, etc., file system,
networking, etc. - even if the application doesn't really needs them.
Unlike Linux we don't have a huge amount of irrelevant stuff (like floppy
disk drivers), but some applications may nonetheless find whole chunks of
OSv to be irrelevant for them, and may want a smaller OSv without them.

For example, we currently support building OSv without a permanent
filesystem (only a ram drive) so it compiles without ZFS in the kernel, and
without ZFS-related tools, which lowers both the image size and memory use.
If you build the silly game "rogue" without a permanent filesystem,
""scripts/build image=rogue fs=ramfs", the resulting image size is only 6.6

In your slide you listed OSv's "size" as 29 MB. I don't know if this refers
to to the image size (which, as I said above, can be much lower) or to the
memory size. OSv's memory size is also "excessive" (in Super Mario
standards) because of some silly compromises we took, such as:

 1. We have a silly lower limit on the memory we use because of reasons
explained in https://github.com/cloudius-systems/osv/issues/195. This lower
limit can be made configurable - currently it is set to about 25 MB.

 2. All the kernel code is loaded into memory, so the more non-useful stuff
we compile in, the more memory we need.

 3. Moreover, some areas of the code use too much memory - for example the
ZFS system starting a bunch of threads (see
https://github.com/cloudius-systems/osv/issues/247) and also a generous
cache, some code uses generous amounts of buffers, etc.

 4. pthread stacks are allocated in advance: see

If anyone is interested to work on these issues, or other directions of
making OSv smaller, I'd be happy :-)

You received this message because you are subscribed to the Google Groups "OSv 
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osv-dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to