[arch-dev-public] mkinitcpio some improvements and question on how kernel modules should be treated

[Morten Linderud]

On Tue, Feb 01, 2022 at 03:54:03PM +0100, Tobias Powalowski via arch-dev-public wrote:
> Hi guys,
> did some initcpio optimizing lately and implemented correct symlink
> handling. This saves already some space.
> https://bugs.archlinux.org/task/73439
> 
> Now one major problem left in recent initcpio, uncompressed modules:
> https://github.com/archlinux/mkinitcpio/pull/25
> https://bugs.archlinux.org/task/72882
> At the moment modules are uncompressed during initcpio creation. This leads
> to bigger RAM usage during boot, makes it a bit smaller on storage, due to
> not recompress compressed modules. On small initrds for normal boot this is
> not a big matter.
> 
> My measurement with all patches added:
> Ramdisk size uncompressed modules: 13261677
> Ramdisk size compressed modules: 13112083
> (Note the compressed one is smaller due to the symlink patches added)
> Unpacked initramfs uncompressed modules: 35 MB
> Unpacked initramfs compressed modules:  26 MB
> Using this on the biggest "initramfs testsuite" archboot shows the most
> advantages.
> 
> If you like to test it on your own initramfs setup you can use:
> https://gitlab.archlinux.org/tpowa/archboot/-/blob/master/usr/share/archboot/patches/31-initcpio.functions.fixed
> for /usr/lib/initcpio/functions and recreate your initramdisk.
> 
> Now my question to the list, what should be the default how arch handles
> modules in initramfs?
> - Shall we leave the modules at compression level used during kernel build?
>  --> This means the uncompression should be optional.
> - Shall we still uncompress the modules always? (Status now)
> --> Then using modules as is needs to be optional.

I think we should leave it as-is and much rather have a flag if someone want to
compress kernel modules or not.

The space increase vs RAM increase vs mkinitcpio build time is something that
it's generally a bit hard to make call on and I reckon there are arguments on
both of these sides.

I wouldn't mind rewriting the patch submitted to mkinitcpio and fix up the
issues it had.

-- 
Morten Linderud
PGP: 9C02FF419FECBE16
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.archlinux.org/pipermail/arch-dev-public/attachments/20220201/9105f41c/attachment.sig>