Re: Current State of C++ Unikernels
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 wrote: > > On Fri, Sep 16, 2016 at 3:28 AM, Ian Eyberg 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.
Re: Current State of C++ Unikernels
On Mon, Sep 19, 2016 at 2:10 AM, Waldek Kozaczuk wrote: > 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? > Yes, it is possible to split off many parts of the OSv kernel into separate shared objects. For example I can imagine moving the entire ZFS code into a separate zfs.so, and loading this object will cause the ZFS support to be added to the kernel, the ZFS partition to be mounted, and so on. However, it will be an effort, and it's not clear what granularity even makes sense: In your example above, you seems to have split the read() and write() features to two different shared objects - I'm not sure that is practical. It's also not clear to me how fine this division should be. Should each individual function (or several related functions) be in a separate object? Or just split it into several large ones? Of course, to make any of this splitting effort worthwhile, one needs to come up with a scenario where the current on-disk size of OSv is excessive. Nadav. -- 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.
Re: Current State of C++ Unikernels
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 > 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.
Re: Current State of C++ Unikernels
On Fri, Sep 16, 2016 at 3:28 AM, Ian Eyberg 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.
Current State of C++ Unikernels
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 -- 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.
