maybe not on an SSD but it definitely helps a lot on HDD by virtue of having far less disk traffic. The kernel's method for figuring out which modules to load is effectively to load every single module that might be compatible with a given device in series and then ask the module for its opinion before unloading it, and then once it has a list of all (self-reported) compatible modules for a given device it picks one and reloads it.
> helps a lot on HDD by virtue of having far less disk traffic
Still doesn't matter because we're talking about init ramdisk here. It's a sequential file loaded into RAM before the kernel. Whether it's 5MB or 20MB would't matter much even on a hard drive. After that it's all in RAM anyway.
Why does it not cache that list for next boot? On hardware changes one could add a boot flag to invalidate the cache.
That may not make sense for all installs, but for power user installs I think it would make sense.
For anything involved in the I/O stack this would be a complete non-starter because having a cache implies the existence of a filesystem which in turn implies the existence of all underlying modules. PCI, network stack, USB, etc can all be necessary prerequisites for that so it's a non-starter for anything involved with them too; at this point we've already ruled out most of the computer.
Also for embedded systems there often isn't a writable filesystem, and that is a huge part of linux's userbase.
Thank you. I'll spend some time to learn why that is not the default config setting.
I doubt that'll affect boot time but it reduces initrd.img size a lot.