From: "Richard W.M. Jones" <rjones@redhat.com>
To: Yang Zhong <yang.zhong@intel.com>
Cc: pbonzini@redhat.com, stefanha@redhat.com, berrange@redhat.com,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] About the light VM solution!
Date: Thu, 7 Dec 2017 12:03:49 +0000 [thread overview]
Message-ID: <20171207120349.GH2450@redhat.com> (raw)
In-Reply-To: <20171205063313.GB4102@yangzhon-Virtual>
I did a bit of work on this back in early 2016 and wrote a paper which
analyzes what Intel were doing with Clear Containers back then, and
how it fitted with the more distribution-centric view of Fedora and
Red Hat, ie that we ideally want a single qemu binary, a single
kernel, a single SeaBIOS, etc.
You can read the paper here:
http://oirase.annexia.org/tmp/paper.pdf
and the source is here:
http://git.annexia.org/?p=libguestfs-talks.git;a=tree;f=2016-eng-talk;h=5a0a29ceb1e9db39539669717ec06e4f94eba086;hb=HEAD
To address a few points from this thread:
* As Paolo mentioned one problem is we link qemu to so many libraries,
and glibc / ELF dynamic loading is very slow. Modularizing qemu
could help here. Reducing symbol interposition
(-fvisibility=hidden) in more libraries would help a bit. Linker
security features enabled in downstream distros don't help.
Rewriting ELF to be less crazy would help a lot but good luck there :-)
* As Stefan & Paolo mentioned, it would be nice if SeaBIOS was faster
in the default configuration. I ended up compiling a special
minimal SeaBIOS which saved a load of time, mainly not probing PCI
unnecessarily IIRC.
* Considerable time is taken in booting the kernel, and that's mostly
in running all the initcall functions. We wanted to use a Fedora
distro kernel, but unfortunately many subsystems do loads of
initcall work which is run even when that subsystem is not used.
This is why compiling a custom kernel (compiling out these
subsystems) is enticing. Parallelizing initialization could help
here (however at the moment using -smp slows things down), also
parallelizing was rejected upstream IIRC.
* PCI config space probing is really slow. Unfortunately accelerating
it in the kernel doesn't seem either very easy or very acceptable to
KVM upstream: the use case is rather narrow & the implementation
seems like it would be very complex. I also write a parallelizing
PCI probe for Linux which helped a bit but wasn't upstream material.
* udev is another huge problem. It's slow, it's monolithic, it
resists modifications such as modularization or removing parts.
* Debugging over the UART is slow.
libguestfs also ships with benchmarking tools which can be very useful
to actually measure boot time:
https://github.com/libguestfs/libguestfs/tree/master/utils
HTH,
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
prev parent reply other threads:[~2017-12-07 12:04 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-12-05 6:33 [Qemu-devel] About the light VM solution! Yang Zhong
2017-12-05 12:06 ` Stefan Hajnoczi
2017-12-05 13:35 ` Paolo Bonzini
2017-12-05 13:47 ` Stefan Hajnoczi
2017-12-05 14:00 ` Paolo Bonzini
2017-12-05 16:31 ` Stefan Hajnoczi
2017-12-06 9:21 ` Gonglei (Arei)
2017-12-06 15:09 ` Stefan Hajnoczi
2017-12-07 0:49 ` Gonglei (Arei)
2017-12-06 15:11 ` Stefan Hajnoczi
2017-12-08 11:29 ` Yang Zhong
2017-12-07 12:03 ` Richard W.M. Jones [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20171207120349.GH2450@redhat.com \
--to=rjones@redhat.com \
--cc=berrange@redhat.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
--cc=yang.zhong@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.