linux-kernel - module boot time (was Re: [PATCH] module: Use binary search in lookup

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4DD435B7.9090702@am.sony.com>
Date:	Wed, 18 May 2011 14:10:15 -0700
From:	Tim Bird <tim.bird@...sony.com>
To:	Greg KH <greg@...ah.com>
CC:	Christoph Hellwig <hch@...radead.org>,
	Alessio Igor Bogani <abogani@...nel.org>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Anders Kaseorg <andersk@...lice.com>,
	Tim Abbott <tabbott@...lice.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Linux Embedded <linux-embedded@...r.kernel.org>,
	Jason Wessel <jason.wessel@...driver.com>,
	Dirk Behme <dirk.behme@...glemail.com>
Subject: module boot time (was Re: [PATCH] module: Use binary search in lookup_symbol())

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:
>> http://elinux.org/images/1/18/C_AMOROSO_Fast_lkm_loader_ELC-E_2009.pdf
>> (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.
 -- Tim

=============================
Tim Bird
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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/