On Sat, Mar 13, 2021 at 10:25:27PM +0100, Rasmus Villemoes wrote: > Most of the boot process doesn't actually need anything from the > initramfs, until of course PID1 is to be executed. So instead of doing > the decompressing and populating of the initramfs synchronously in > populate_rootfs() itself, push that off to a worker thread. > > This is primarily motivated by an embedded ppc target, where unpacking > even the rather modest sized initramfs takes 0.6 seconds, which is > long enough that the external watchdog becomes unhappy that it doesn't > get attention soon enough. By doing the initramfs decompression in a > worker thread, we get to do the device_initcalls and hence start > petting the watchdog much sooner. > > Normal desktops might benefit as well. On my mostly stock Ubuntu > kernel, my initramfs is a 26M xz-compressed blob, decompressing to > around 126M. That takes almost two seconds: > > [ 0.201454] Trying to unpack rootfs image as initramfs... > [ 1.976633] Freeing initrd memory: 29416K > > Before this patch, these lines occur consecutively in dmesg. With this > patch, the timestamps on these two lines is roughly the same as above, > but with 172 lines inbetween - so more than one cpu has been kept busy > doing work that would otherwise only happen after the > populate_rootfs() finished. > > Should one of the initcalls done after rootfs_initcall time (i.e., > device_ and late_ initcalls) need something from the initramfs (say, a > kernel module or a firmware blob), it will simply wait for the > initramfs unpacking to be done before proceeding, which should in > theory make this completely safe. > > But if some driver pokes around in the filesystem directly and not via > one of the official kernel interfaces (i.e. request_firmware*(), > call_usermodehelper*) that theory may not hold - also, I certainly > might have missed a spot when sprinkling wait_for_initramfs(). So > there is an escape hatch in the form of an initramfs_async= command > line parameter. > > Signed-off-by: Rasmus Villemoes <[email protected]>
Reviewed-by: Luis Chamberlain <[email protected]> Luis
