Libguestfs appliance boot in under 600ms

$ ./run ./utils/boot-benchmark/boot-benchmark
Warming up the libguestfs cache ...
Running the tests ...

test version: libguestfs 1.33.28
 test passes: 10
host version: Linux 4.4.4-301.fc23.x86_64 #1 SMP Fri Mar 4 17:42:42 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
    host CPU: Intel(R) Core(TM) i7-5600U CPU @ 2.60GHz
     backend: direct               [to change set $LIBGUESTFS_BACKEND]
        qemu: /home/rjones/d/qemu/x86_64-softmmu/qemu-system-x86_64 [to change set $LIBGUESTFS_HV]
qemu version: QEMU emulator version 2.5.94, Copyright (c) 2003-2008 Fabrice Bellard
         smp: 1                    [to change use --smp option]
     memsize: 500                  [to change use --memsize option]
      append:                      [to change use --append option]

Result: 575.9ms Β±5.3ms

There are various tricks here:

  1. I’m using the (still!) not upstream qemu DMA patches.
  2. I’ve compiled my own very minimal guest Linux kernel.
  3. I’m using my nearly upstream "crypto: Add a flag allowing the self-tests to be disabled at runtime." patch.
  4. I’ve got two sets of non-upstream libguestfs patches 1, 2
  5. I am not using libvirt, but if you do want to use libvirt, make sure you use the very latest version since it contains an important performance patch.



Filed under Uncategorized

4 responses to “Libguestfs appliance boot in under 600ms

  1. mkowp

    Very impressive! I think I’ll wait till the patches to be incorporated and live vicariously through you. I’d say “post a video” but if I blinked I might miss the boot. πŸ˜‰

    • rich

      Not a lot to see in a video I’m afraid …

      Most of the patches should go upstream soon, and many will be included in RHEL 7.3. However a custom kernel isn’t going to happen, and that will add 200ms or so.

  2. someone

    Tried kvmtool & Clear Containers?

    • rich

      Of course. I’m giving a talk about this at KVM Forum. kvmtool isn’t the answer because it doesn’t support a multitude of features used by libguestfs, and by the time you’ve added all those features, you’ve ended up with qemu. qemu isn’t slow because it has extra features – those features just sit on disk until you use them. Clear Containers has massive non-upstream kernel & systemd (and kvmtool) hacks. My aim is to make this upstreamable and supportable.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.