module boot time (was Re: [PATCH] module: Use binary search in lookup_symbol())
From: Tim Bird
Date: Wed May 18 2011 - 17:10:44 EST
On 05/18/2011 12:21 PM, Greg KH wrote:
> On Wed, May 18, 2011 at 10:00:12AM -0700, Tim Bird wrote:
>> Carmelo Amoroso reported some good performance gains
>> in this presentation:
>> (See slide 22).
>> He doesn't report the overall time savings, and
>> he was using a different method (hash tables as opposed to
>> binary search), but I believe the results are comparable
>> to what the binary search enhancement provides.
>> The biggest offenders in his testing were usbcore,
>> ehci_hcd and ohci_hcd.
> Why those? The size of them, or something else? They don't seem to
> have very many symbols they need to look up compared to anything else
> that I can tell.
> Is something else going on here due to the serialization of the USB
> drivers themselves?
I don't think there's anything wrong with these, compared to
other kernel modules. I just think they stood out (probably
because of size) from the other modules in the small set that
Carmelo tested. In his tests, usbcore was the largest module
by an order of magnitude.
>>> And why do people overly care for the load time?
>> To reduce overall boot time.
> To reduce it even more, build the modules into the kernel :)
That's what I do most of the time. For some projects,
it is useful to build certain things as modules so you can
defer initializing them until later in the boot sequence.
You can get some critical user-space tasks running, then
come back later to initialize USB and other drivers.
On cameras, it's not uncommon to want to get to user
space in the first 500 milliseconds.
Sony has some code which allows us to both statically link
drivers and defer their initialization, but it's kind of
kludgy and requires modifying the module declarations
for the code you want to defer. Let me know if you think
this is worth doing an RFC about.
Architecture Group Chair, CE Workgroup of the Linux Foundation
Senior Staff Engineer, Sony Network Entertainment
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/