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 <[email protected] > <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 [email protected]. For more options, visit https://groups.google.com/d/optout.
