On Tue, 26 Apr 2022 13:39:08 -0700, Andrew Morton wrote:
> On Mon, 4 Apr 2022 11:34:27 +0200 David Disseldorp <ddiss@xxxxxxx> 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
