| |||||||||||||
LinuxCon: A tale of two bootchartsLinuxCon: A tale of two bootchartsPosted Aug 26, 2010 22:26 UTC (Thu) by Jonno (subscriber, #49613)In reply to: LinuxCon: A tale of two bootcharts by Trelane Parent article: LinuxCon: A tale of two bootcharts
What specifically is the slow part of modules? Having to suck them in individually? Actually, modules loaded after rootfs is mounted isn't the problem. The problem is the initramfs, ormore acurately vmlinuz+initramfs . So simply building all modules normaly included in the initramfs into the kernel won't help either (well, you do loose the early userspace bits, which helps somewhat, but are neglible in the big picture). What you need is fewer modules to load prior to rootfs is mounted, and that can only be done by knowing the hardware in advance. 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. A kernel/bios boundary is essentially the same as a userspace/kernel boundrary, but bioses are generally crappy, and will usually trash all register, most or all L1 cache, and up to 1MB of the L3 cache. Doing that thirty-five-thousands-and-thirty-seven (35,037) times (my Ubuntu netbook) can take a few seconds...
(Log in to post comments)
LinuxCon: A tale of two bootcharts Posted Aug 27, 2010 14:57 UTC (Fri) by BenHutchings (subscriber, #37955) [Link]
"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.
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.
|
|||||||||||||