mkimg: Optimize boot times & initramfs build times #19
Conversation
- By default, mkinitcpio decompresses kernel modules into a temporary directory when building initramfs, then compresses the resulting initramfs fully as a single blob - This default behavior might have been faster on some beefy x86_64 CPU, and also in the past when firmware wasn't compressed, we didn't have ZSTD etc, but in modern RISC-V reality it slows things down big time, because now the kernel has to decompress the whole huge initramfs at once upon initial boot instead of separately decompressing individual modules/firmware blobs. It doesn't help that firmware is seemingly compressed twice... - This patch to the mkinitcpio config shaves around 30 seconds of boot time on QEMU on my machine, and around 20 seconds of boot time on RVVM. Results from real boards are welcome (But I've definitely seen they also suffer from this slow initramfs decompression issue) - Perhaps it is possible to patch the default Arch RISC-V mkinitcpio package config instead, but I guess this is a less invasive proposal for those who might be interested in optimizing boot time right now
Have you compared the initrd size? We have met too big initrd problem on D1 device before...
But it's more dirty... |
I can easily boot fallback initrams on 256M RAM given to the VM. Any lower and U-Boot crashes however - it's a QEMU U-Boot config so it's really not configured to work below that (btw if anyone can help me with this, I'd be very thankful). If not for the U-Boot issue, I imagine we could boot default initramfs on somewhere around 64-128M of RAM.
Yes. If you are impressed with the results as much as I am, hopefully we can ask for a package config change instead. |
If that will have no visible disk size change, I think this change should be sent to mkinitcpio upstream as default config. Because it's a Pareto Improvement. |
I am not entirely sure they will accept this right away and am shy. However, I can also see a few second reduction in boot times on my laptop with an Intel CPU and NVMe. I will try to send such a patch upstream. If they won't accept it, I hope we can implement this in Arch RISC-V package. |
By default, mkinitcpio decompresses kernel modules into a temporary directory when building initramfs, then compresses the resulting initramfs fully as a single blob
This default behavior might have been faster on some beefy x86_64 CPU, and also in the past when firmware wasn't compressed, we didn't have ZSTD etc, but in modern RISC-V reality it slows things down big time, because now the kernel has to decompress the whole huge initramfs at once upon initial boot instead of separately decompressing individual modules/firmware blobs. It doesn't help that firmware is seemingly compressed twice...
This patch to the mkinitcpio config shaves around 30 seconds of boot time on QEMU on my machine, and around 20 seconds of boot time on RVVM. Results from real boards are welcome (But I've definitely seen they also suffer from this slow initramfs decompression issue).
Perhaps it is possible to patch the default Arch RISC-V mkinitcpio package config instead, but I guess this is a less invasive proposal for those who might be interested in optimizing boot time right now
I'd also like to see some way to omit
linux-firmwarefrom being installed in the resulting image, but I am not sure how to implement it properly or what arg syntax would be acceptable. Thx for any advice or help.