Interesting - thanks for the notes!
I wouldn't read too much into the comparison slide - it was more of an
overview slide. I think one of the areas the unikernel ecosystem at
large is severely lacking in is education. Many of the people I talk
to depending on their sets of communities they belong to will only
recognize one unikernel and not even know there are 10+ others and
this is extracted from the set of people that don't dump unikernels
into the container ecosystem or from people that even recognize the
term. Someone at the meetup had asked what it would take to get
unikernel adoption going strong and my simple answer was education -
the technology is not a problem (speaking to a room full of
engineers).
The size slides were referring to disk image size. That was just a
simple hello world tutorial I found on the website. To be honest I
have not worked much with OSv yet compared to some others, but it's
definitely sparked my interest and I'm going to spend some more time.
re: education - for instance most of last year I was unaware that it
supported more than the JVM ecosystem.
I don't think the base image size is a huge limiting factor as long as
it's not outrageous. That is to say - deploys should be relatively
quick and not take 10-15minutes to upload a gig+ size image. Other
than that the image size is not that big of a deal to me as most
applications will use more 'expensive' resources in terms of
allocation such as ram. The disk size arguments make much more sense
when you start talking about the more usecase specific implementations
out there that service things for NFV and the like - not necessarily
web applications.
On Sun, Sep 18, 2016 at 9:08 AM, Nadav Har'El <n...@scylladb.com> wrote:
>
> 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
> MB.
>
> 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
> https://github.com/cloudius-systems/osv/issues/143
>
> 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.
