Package: sbuild-qemu Version: 0.83.1 Severity: wishlist X-Debbugs-Cc: Christian Kastner <c...@debian.org>
One drawback of using qemu instead of schroot is some performance impact. Thanks to KVM and hardware support, the runtime impact should be close to negligible, yet I still feel qemu is "slower" than schroot. In a past conversation on my blog: https://anarc.at/blog/2022-04-27-sbuild-qemu/#comment-e7d79610367619142249204262d3c342 ... this was brought up and a few improvements were suggested: 1. reduce the GRUB_TIMEOUT 2. optimizing initramfs 3. look at alternative runtimes (microvm, firecracker, etc) So I looked into this a little, and I found the following... GRUB_TIMEOUT is actually set a *few* times in the `/etc/default/grub` configuration file. Over here the last lines look like this: GRUB_CMDLINE_LINUX_DEFAULT="biosdevname=0 net.ifnames=0 consoleblank=0 systemd.show_status=true rw loglevel=3 console=tty0 console=ttyS0,115200n8" GRUB_ENABLE_CRYPTODISK=y GRUB_TIMEOUT=0 GRUB_TERMINAL=serial GRUB_SERIAL_COMMAND="serial --speed=115200 --unit=0 --word=8 --parity=no --stop=1" GRUB_TIMEOUT=1 So I think that, as ckk stated in the comment, setting GRUB_TIMEOUT=0 would help a little, but maybe we could also just remove that from `/usr/share/sbuild/sbuild-qemu-create-modscript` altogether. I did some rough "wall clock" timing here, and here's what I could count: * grub: ~1 second * linux: < 1 second, negligible * initrd: 4-6 seconds? Then the rest of the boot process takes on, and there we have actual timestamps thanks to the console messages. I include the full log below, but a few key points (all times below are from *after* the above 4-5 seconds of kernel load time): * /init starts only after 1.45 seconds, this could probably be improved by trimming the initrd? * systemd itself starts to run actual things only after 3 seconds! * the console shows up after about 5 seconds The entire boot operation seems to take about 12-13 seconds, which is really noticeable. Here's the top 10 offenders according to systemd: root@host:~# systemd-analyze blame | head -10 1.526s dev-sda1.device 1.152s ifupdown-pre.service 855ms systemd-journal-flush.service 323ms networking.service 216ms systemd-random-seed.service 216ms systemd-udev-trigger.service 213ms systemd-sysusers.service 190ms systemd-tmpfiles-setup-dev.service 183ms systemd-journald.service 182ms systemd-udevd.service kind of fascinating to have the VM wait a whole 1.5 seconds for "sda1"! and how about that full one second for ifupdown? maybe networkd could help? Anyways, that's what I got. I manually modified my VM images to avoid the grub delay, but I do think trimming down the initrd and tweaking systemd could help quite a bit here. Thanks! -- System Information: Debian Release: 11.3 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable-debug'), (500, 'stable'), (1, 'unstable'), (1, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 5.10.0-14-amd64 (SMP w/4 CPU threads) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=fr_CA.UTF-8, LC_CTYPE=fr_CA.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages sbuild-qemu depends on: ii autopkgtest 5.21 ii python3 3.9.2-3 ii python3-pexpect 4.8.0-2 ii python3-psutil 5.8.0-1 ii qemu-system-x86 1:5.2+dfsg-11+deb11u2 ii qemu-utils 1:5.2+dfsg-11+deb11u2 ii sbuild 0.81.2 ii vmdb2 0.22-1 Versions of packages sbuild-qemu recommends: ii qemu-system-arm 1:5.2+dfsg-11+deb11u2 ii qemu-system-ppc 1:5.2+dfsg-11+deb11u2 sbuild-qemu suggests no packages. -- no debconf information
