OSv has already a concept of module but I wonder if its core can be made modular as well. For example there could be something like osv.base, osv.io (osv.io.read, osv.io.write, etc), osv.net, etc I do not know enough it it makes sense but even POSIX systems calls can be grouped into modules and then pulled like lego blocks depending on what one needs. I am looking at the modularity of Java 9 runtime (http://openjdk.java.net/jeps/220) which I am trying to draw an parallel to.
Would it be possible? Is it a big effort? On Sunday, September 18, 2016 at 12:08:22 PM UTC-4, Nadav Har'El wrote: > > > On Fri, Sep 16, 2016 at 3:28 AM, Ian Eyberg <i...@deferpanic.com > <javascript:>> 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.
