Bug#652525: Make initramfs-tools faster by avoiding forks in the per-module hot path
On Sat, Dec 17, 2011 at 10:37:29PM -0800, Josh Triplett wrote:
> In the last few versions of initramfs-tools, update-initramfs started
> taking an excessively long time to generate the initramfs:
>
> ~$ time sudo update-initramfs -u
> update-initramfs: Generating /boot/initrd.img-3.1.0-1-amd64
>
> real 0m26.197s
> user 0m14.785s
> sys 0m1.196s
>
> This results in a long delay every time I upgrade either a kernel or any
> package with an update-initramfs hook.
>
> As far as I can tell, a large part of this processing time seems to
> consist of the per-module processing for the ~500 kernel modules copied
> into the initramfs, forking off a pile of programs for each one. I
> tried optimizing the per-module hot path to eliminate as many forks as
> possible, and managed to speed it up considerably:
>
> ~$ time sudo update-initramfs -u
> update-initramfs: Generating /boot/initrd.img-3.1.0-1-amd64
>
> real 0m21.385s
> user 0m14.393s
> sys 0m0.740s
>
> I've attached a patch implementing these optimizations.
>
> A few other possible improvements:
>
> - Generate a list of modules and processing them all in batch at the
> end of update-initramfs, to allow calling modprobe and modinfo only
> once. Likely to make a huge difference.
> - In the absence of the above, make manual_add_modules take a list of
> modules and process them all, and make the various hooks pass a list
> of modules to manual_add_modules rather than calling it repeatedly.
I implemented this addition, making manual_add_modules take multiple
arguments, and it provided another significant performance improvement:
~$ time sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-3.1.0-1-amd64
real 0m18.763s
user 0m14.569s
sys 0m0.720s
The difference between the original and patched versions in terms of
executed programs:
Bug#652525: Make initramfs-tools faster by avoiding forks in the per-module hot path
