Re: [PATCH v7 3/6] initramfs: add INITRAMFS_PRESERVE_MTIME Kconfig option

[David Disseldorp <ddiss@suse.de>]

On Tue, 26 Apr 2022 13:39:08 -0700, Andrew Morton wrote:

> On Mon,  4 Apr 2022 11:34:27 +0200 David Disseldorp <ddiss@suse.de> wrote:
> 
> > initramfs cpio mtime preservation, as implemented in commit 889d51a10712
> > ("initramfs: add option to preserve mtime from initramfs cpio images"),
> > uses a linked list to defer directory mtime processing until after all
> > other items in the cpio archive have been processed. This is done to
> > ensure that parent directory mtimes aren't overwritten via subsequent
> > child creation.
> > 
> > The lkml link below indicates that the mtime retention use case was for
> > embedded devices with applications running exclusively out of initramfs,
> > where the 32-bit mtime value provided a rough file version identifier.
> > Linux distributions which discard an extracted initramfs immediately
> > after the root filesystem has been mounted may want to avoid the
> > unnecessary overhead.
> > 
> > This change adds a new INITRAMFS_PRESERVE_MTIME Kconfig option, which
> > can be used to disable on-by-default mtime retention and in turn
> > speed up initramfs extraction, particularly for cpio archives with large
> > directory counts.
> > 
> > Benchmarks with a one million directory cpio archive extracted 20 times
> > demonstrated:
> > 				mean extraction time (s)	std dev
> > INITRAMFS_PRESERVE_MTIME=y		3.808			 0.006
> > INITRAMFS_PRESERVE_MTIME unset		3.056			 0.004  
> 
> So about 35 nsec per directory?

~750 nsec - I should have clarified that the "20" refers to the number
of runs over which the "mean extraction time" is averaged.

> By how much is this likely to reduce boot time in a real-world situation?

Not much, although my xfstests initramfs images tend to get into the
hundreds of directories. These numbers were captured using QEMU/kvm on
my laptop - I could rerun the benchmark on an old ARM SBC if more data
points are needed.

Cheers, David