the slowest part is deciding if the module should be loaded or not, and if you load a module that isn't needed, waiting for the module to decide that the hardware it's trying to initialize really isn't there.
a monolithic kernel that is tailored for your hardware (includes all the drivers you need and few or none that you don't) will boot up _much_ faster as a result.
Posted Aug 27, 2010 18:04 UTC (Fri) by Trelane (subscriber, #56877)
[Link]
deciding if the module should be loaded or not, and if you load a module that isn't needed, waiting for the module to decide that the hardware it's trying to initialize really isn't there.
I think the remedy for this could be implemented as I replied back to the other subthread. I don't know, however, if this is at all feasible, but the core problem is that upon first boot the kernel doesn't know what hardware is present and what isn't. Supplying information pertaining to what is likely to be found again (a simple list with information on what modules were most recently used would be a simpler algorithm, and since it could clearly rely on userspace tools to put together the information, this could be a policy thing) would avoid this. The problem would then be making sure we fall back gracefully (simple idea would be to just fall back to scanning as is currently done).