<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 27 Jul 2023 at 09:21, Benjamin Drung <<a href="mailto:bdrung@ubuntu.com">bdrung@ubuntu.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Wed, 2023-07-26 at 17:53 +0200, Benjamin Drung wrote:<br>
> Hi all,<br>
> <br>
> A few weeks ago, I posted an idea how to reduce the initramfs size and<br>
> speed up the generation:<br>
> <br>
> <a href="https://lists.ubuntu.com/archives/ubuntu-devel/2023-July/042652.html" rel="noreferrer" target="_blank">https://lists.ubuntu.com/archives/ubuntu-devel/2023-July/042652.html</a><br>
> <br>
> This post sparked a lively discussion. The initial idea was ditched for<br>
> a better solution: mkinitramfs will put all compressed files (kernel<br>
> modules and firmware files) into a cpio archive that is not compressed<br>
> (because compressing compressed files makes no sense). All other files<br>
> will be added to a cpio archive that gets compressed. As next steps, the<br>
> kernel modules and firmware files need to be shipped compressed.<br>
> <br>
> After several iterations for the implementation and review by Daves<br>
> Jones, I just uploaded initramfs-tools 0.142ubuntu8 to mantic that puts<br>
> compressed kernel modules and firmware files in an uncompressed cpio<br>
> (<a href="https://launchpad.net/bugs/2028567" rel="noreferrer" target="_blank">https://launchpad.net/bugs/2028567</a>).<br>
> <br>
> I created/updated the follow-up tickets and added my patches to them:<br>
> <br>
> Ship kernel modules Zstd compressed<br>
> <a href="https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2028568" rel="noreferrer" target="_blank">https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2028568</a><br>
> <br>
> compress firmware in /lib/firmware<br>
> <a href="https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1942260" rel="noreferrer" target="_blank">https://bugs.launchpad.net/ubuntu/+source/linux-firmware/+bug/1942260</a><br>
> <br>
> And without further ado, here come the benchmark results:<br>
> <br>
> The benchmarks were done either on an AMD Ryzen 7 5700G with schroot and<br>
> overlay on tmpfs or on the hardware mentioned. All tests were running<br>
> the latest Ubuntu mantic development release.<br>
> <br>
> * minimal: schroot with linux-image-generic initramfs-tools zstd<br>
> * full: minimal + busybox-initramfs cryptsetup-initramfs<br>
>   isc-dhcp-client kbd lvm2 mdadm ntfs-3g plymouth plymouth-theme-spinner<br>
> * nvidia: full + linux-headers-generic nvidia-driver-525<br>
> * nvidia fw: nvidia + compressed /lib/firmware/nvidia/525.125.06/<br>
> * VisionFive 2: VisionFive 2 RISC-V board<br>
> * RPi Zero 2: Raspberry Pi Zero 2 ARM board (running armhf)<br>
> <br>
> "next" means using kernel/firmware/initramfs from ppa:bdrung/ppa i.e.<br>
> * initramfs-tools 0.142ubuntu7bd4<br>
> * linux 6.3.0-7.7bd2<br>
> * linux-firmware 20230629.gitee91452d-0ubuntu1bd1<br>
> <br>
> > |                | build   | size               | uncompressed size  |<br>
> > | test           | time    | in bytes  | in MiB | in bytes  | in MiB |<br>
> > |----------------|---------|-----------|--------|--------------------|<br>
> > | minimal        | 4.30 s  |  66701818 |  63.6  | 224087608 | 213.7  |<br>
> > | minimal next   | 4.54 s  |  59935186 |  57.2  |  67738810 |  64.6  |<br>
> > | full           | 7.15 s  | 118007038 | 112.5  | 387976843 | 370.0  |<br>
> > | full next      | 7.29 s  | 106937908 | 102.0  | 128610985 | 122.7  |<br>
> > | nvidia         | 7.04 s  | 209200523 | 199.5  | 513554279 | 489.8  |<br>
> > | nvidia next    | 7.21 s  | 195246287 | 186.2  | 235288174 | 224.4  |<br>
> > | nvidia fw next | 7.16 s  | 191329102 | 182.5  | 213078234 | 203.2  |<br>
> > | VisionFive 2   | 142.9 s | 121895035 | 116.2  | 411160836 | 392.1  |<br>
> > | VF 2 next      | 126.7 s | 111651453 | 106.5  | 134120804 | 127.9  |<br>
> > | RPi Zero 2     | 109.5 s |  39803044 |  40.0  |  69592789 |  66.4  |<br>
> > | RPi Zero 2 ²   | 103.5 s |  39804499 |  40.0  |  69592789 |  66.4  |<br>
> > | RPi Zero 2 next| 101.2 s |  31463352 |  30.0  |  41145762 |  39.2  |<br>
> <br>
> ² Updated initramfs-tools (but no compressed modules or firmware)<br>
> <br>
> The build time was averaged over five runs.<br>
> <br>
> > | improvement  | build time | size   | uncompressed size |<br>
> > |--------------|------------|--------|-------------------|<br>
> > | minimal      |  105.6 %   | 89.9 % |      30.2 %       |<br>
> > | full         |  102.0 %   | 90.6 % |      33.1 %       |<br>
> > | nvidia       |  101.7 %   | 91.5 % |      41.5 %       |<br>
> > | VisionFive 2 |   88.7 %   | 91.6 % |      32.6 %       |<br>
> > | RPi Zero 2   |   92.4 %   | 79.0 % |      59.1 %       |<br>
> <br>
> Building the initramfs takes more CPU cycles (see tests on tmpfs), but<br>
> saves time on disk IO. Daves Jones saw much bigger time savings on his<br>
> Raspberry Pis but his tests were on lunar.<br>
> <br>
> Build time influence:<br>
> + add_directories plus uniq take several milliseconds<br>
> + depmod on compressed kernel modules take hundreds of<br>
>   milliseconds longer<br>
> - copying smaller kernel modules (due to compression) is faster<br>
> - cpio archive that needs to be compressed is smaller<br>
> - not storing intermediate cpio archives saves time<br>
> <br>
> Saving 10 to 20 percent on the initramfs size and only needing half or a<br>
> third of the size when unpacked (i.e. needed memory during boot) is a<br>
> good improvement.<br>
<br>
The smaller initramfs overall size (less to load into memory and unpack)<br>
and the smaller compressed cpio (less to decompress) have a positive<br>
effect on the boot speed, especially on systems with slow CPU and/or<br>
slow IO.<br>
<br>
When looking at the "kernel" time from systemd-analyze, the improvement<br>
ranges from 1.62s - 1.36s = 0.26s in a VM on my desktop to a heavily<br>
noticeable 37.9s - 16.5s = 21.4s on the VisionFive 2 RISC-V board.<br></blockquote><div><br></div><div>This is good stuff. It's a bit of a shame that the build time for the initramfs hasn't improved much. I guess it's not as dominated by compression time as I thought?</div><div><br></div><div>Do you have any thoughts about making it faster? I know I once ran 'strace -ff mkinitramfs' and ended up with tens or hundreds of thousands of trace files so not having everything done by a billion tiny shell scripts would help, but I don't know how much.</div><div><br></div><div>I wonder if we can make depmod incremental somehow?</div><div><br></div><div>Cheers,</div><div>mwh </div></div></div>