| |||||||||||||
LinuxCon: A tale of two bootchartsLinuxCon: A tale of two bootchartsPosted Aug 27, 2010 14:57 UTC (Fri) by BenHutchings (subscriber, #37955)In reply to: LinuxCon: A tale of two bootcharts by Jonno Parent article: LinuxCon: A tale of two bootcharts
"The problem is that vmlinuz and initramfs must be loaded prior to accessing the driver for your sata/pata/scsi/etc controller. There are special bios calls that let you do this, but those are crappy. Each call only fetches a single block (512 bytes) and requires a pass through the kernel/bios boundary as well as a call to the harddrive."
No, it's not that bad; you can read multiple sectors at a time. And the kernel is not involved at this point. There's just a boot loader which is probably running in real mode, at least while it's looping over the block list.
The annoying thing about driver modules is that module initialisation, which includes binding to and probing all the devices they can handle, is serialised. Initialisation of built-in drivers can be parallelised. I assume this is hard to change, otherwise someone would have done it already.
(Log in to post comments)
LinuxCon: A tale of two bootcharts Posted Aug 27, 2010 18:00 UTC (Fri) by Trelane (subscriber, #56877) [Link]
I am painfully aware that I'm hitting the envelope of my knowledge, pretty hard.
"The annoying thing about driver modules is that module initialisation, which includes binding to and probing all the devices they can handle, is serialised."
It strikes me, however, that the basic problem *here* is finding out what hardware is present and not present. In the vast majority of cases, I'd wager that this really only needs done once (rather like the crypto hardware tests): upon installation. Beyond that, what's needed is graceful fallback for the rarer cases the hardware isn't present anymore, and what we already have: new hardware detection.
This could be mitigated by means of a table of "known to be present" hardware information supplied to a bulk-loaded module set (something along the lines of putting all the .ko's into a single .ko with tables specifying that it's a bulk module and where everybody's at in it, as outlined above.) If intialization of the known hardware fails, then it could perhaps fall back to probing.
LinuxCon: A tale of two bootcharts Posted Aug 27, 2010 20:13 UTC (Fri) by BenHutchings (subscriber, #37955) [Link] It strikes me, however, that the basic problem *here* is finding out what hardware is present and not present. I think you're confused about how hardware probing is done. Back in the 90s PCs would have a load of ISA devices that each had to be probed in their own way. Today almost every device is described by ACPI tables or the standard PCI or USB configuration mechanisms. The kernel uses these to find which devices are present and only invokes the drivers associated with them. It also sends events out to udev, which loads modules if needed. The 'probing' I refer to involves drivers checking which variant is present and then initialising it appropriately; drivers that you don't need will never be invoked. (There are exceptions, e.g. 8139cp and 8139too handle different devices with overlapping sets of device IDs. Normally they will both be loaded and may both probe the same device.) This could be mitigated by means of a table of "known to be present" hardware information supplied to a bulk-loaded module set (something along the lines of putting all the .ko's into a single .ko with tables specifying that it's a bulk module and where everybody's at in it, as outlined above.) That might be worth a try.
LinuxCon: A tale of two bootcharts Posted Aug 27, 2010 20:21 UTC (Fri) by Trelane (subscriber, #56877) [Link] I think you're confused about how hardware probing is done.Oh, that's a virtual certainty. ;) [excellent lesson here; thanks!] The 'probing' I refer to involves drivers checking which variant is present and then initialising it appropriately; drivers that you don't need will never be invoked.Is this part done via ACPI, as outlined above? Or is this done 90's style? What's the slow part of this, precisely? Is it the initialization? If so, why is it significantly faster to have the module in-kernel? That might be worth a try.wish I had time to. It sounds like perhaps a rather extensive project, as it touches on fundamentals of how things work. If static linking is truly a significant portion of the boot process, though, it might well be worth it. Only testing would tell.
|
|||||||||||||