On Wed, Dec 08, 2021 at 09:51:44AM -0800, Heinrich Schuchardt wrote: > The memory should only be one factor to be taken into account. The SiFive > Unmatched and the RPi 4 boards both have 8 GiB but slow CPUs. It would be > advisable to use a lower compression level on these.
The Pi 4 is limited by I/O performance a lot, -1 is only 10% faster than -12, as seen above, I'd guess it's the same for the sifive. You need *fast* IO with slow CPU to get a problem. > > Could the post install script of initramfs-tools measure the compression > speed and adjust the compression level? The --adapt mode would do that automatically for us, ensuring that it compresses as fast as the I/O can go. Problematic is that it is too fast, if we spent a couple seconds collecting modules and then compress a complete cpio archive, the latter might have irrelevant I/O overhead. The most interesting solution would be to create the cpip archive dynamically by giving cpio a list of files over a pipe that we create dynamically in the hooks as we copy files in, then pipe that to zstd --adapt; then it would all work super nicely. We could also cache compression and total runtime in mkinitramfs and then increase the compression level each time until it causes 10% elapsed runtime overhead, but it's very load dependent I suppose. -- debian developer - deb.li/jak | jak-linux.org - free software dev ubuntu core developer i speak de, en -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
