> 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
