On Thu, Jun 11, 2020 at 6:33 AM Waldek Kozaczuk <[email protected]> wrote:
> > > On Thursday, June 11, 2020 at 2:25:06 AM UTC-4 Pekka Enberg wrote: > >> Hi Dor, >> >> On Thu, Jun 11, 2020 at 8:21 AM Dor Laor <[email protected]> wrote: >> >>> Waldek, can you please describe what's your motivation in shrinking >>> the size of the kernel? Compared for example to modern RAM and also >>> to the JVM that many times will be there, the current size is already >>> 'small enough', isn't it? >>> >> >> Not necessarily if the lifetime of a VM is in the order of, say, hundreds >> of milliseconds. >> >> My understanding is that these extreme optimizations to reduce size are >> motivated by the emergence of light-weight VMs, which allow cloud providers >> to launch VMs on-demand for a group of service requests. This allows them >> to more efficiently utilize the hardware because an idle VM still consumes >> some resources. And in any case, smaller image size anyway means shorter >> boot time and more packing of VMs per node. >> > Exactly. The density is the main motivation. But also somewhat better > security - the app has only access to (in terms of the dynamic linker at > least) to the subset of libc so at least in theory it should not be able to > do anything else than advertised per its ELF. > > With the kernel of size 2.7M we can run hello app on OSv with 11M memory > only (~5MB less) and boot 1-2ms faster - now I pretty consistently get boot > times of ~4ms on firecracker (20-30% faster). > 4ms is pretty amazing, it makes OSv+kvm/firecracker a good candidate for lambdas. For heavier weight frameworks like JVMs, the best would be to preboot them and load the app dynamically. > > Another advantage is that there are fewer symbols in the kernel the > dynamic linker has to search to resolve. I know it uses a hashmap that > makes things pretty fast already but still smaller the hashmap with smaller > buckets the faster lookup should be. > > Finally, whatever mechanism to build custom kernels is, it should also > account for the usage of syscall instruction and properly eliminate stuff > from linux.cc so that the linker can garbage collect even better. > >> >> - Pekka >> > -- > 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]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/osv-dev/1af0216b-a783-47d5-972c-6ea3d5eb262an%40googlegroups.com > <https://groups.google.com/d/msgid/osv-dev/1af0216b-a783-47d5-972c-6ea3d5eb262an%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/osv-dev/CAKUaUn6BqT5JcbjwGUmcUq-Ey2NVofN_za47TSx_FAFBKpvnoA%40mail.gmail.com.
