Thanks for raising this discussion, Julian!
On Wed, Dec 08, 2021 at 06:12:43PM +0100, Julian Andres Klode wrote:
> ## Adaptive compression
> zstd also supports adaptive compression, compressing as hard as
> it can while not impacting I/O speed. So hardware with slow I/O
> like a Pi would compress harder to avoid idling.
> This is somewhat suboptimal with recent update-initramfs though,
> as it first writes the cpio archive to the disk and then compresses
> it rather than doing it in a pipe where that would be more
> meaningful.
> Question: Does zstd --adapt adapt to memory available?
One concern I have here: for upgrades, the size of the resulting initramfs
needs to be reasonably predictable in order for the upgrader to ensure
there's space on the /boot partition for the upgrade to complete, rather
than dying mid-upgrade. If zstd --adapt results in significantly different
sized output based on the I/O load of the system at the time the command is
run, this could negatively impact the upgrades (either in bugs, or in the
upgrader needing to be more conservative in estimating size for the target
release and blocking more users with small /boot from being able to upgrade
at all).
> # Way(s) forward
>
> To remedy the issue the proposal is to build with
> - zstd -1 on hardware with 512 MB or less memory
> - zstd between -1 and -19 on other hardware
> - zstd -19 during image building
> Finding the right level between -1 and -19 is hard. The more
> cores you have, the less penalty you pay for higher level.
> Going for adaptive compression would remove the guess work, but
> will result in larger images on faster machines. Maybe that's
> fine, though - they probably have more space on /boot anyway?
The two reasons to care about size of the resulting initramfs are disk space
(particularly of concern on systems with a separate /boot that were
installed many releases ago, when we didn't mandate as much space for
/boot); and boot speed.
On x86 systems, firmware implementations for accessing the disk are
generally speedy enough that we don't care about the time it takes them to
load the initramfs from disk.
On !x86 systems, particularly embedded systems where the firmware may have
to load the kernel and initrd from a slow MMC device, the size of the
initramfs is more likely to have an impact on boot speed.
Unfortunately, there is a correlation between systems with low memory and
slower CPUs, and systems with slower I/O; so I'm not sure this gives any
greater clarity wrt the right setting to use for such systems.
> If we want to aim for 5% of total memory, we should probably
> aim for something like:
> -1 on <= 512MB
> -6 on <= 2 GB (or --adapt=min=1,max=6)
> -12 on the rest (or --adapt=min=12)
> It's clear that in all cases, zstd -1 is at least better than the
> lz4 -9 we used before; both in terms of space used, and time spent.
That seems pretty sensible to me.
And please, expose the compression level as an argument under /etc so that
an admin can override it as necessary instead of it being hard-coded!
> # Concerns
> Lowering the compression level will reduce the boot speed by fractions
> of a second on hardware with fast I/O.
I think we should also be concerned about reductions in boot speed by
multiples of a second on hardware WITHOUT fast I/O :)
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer https://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
