very common kernel modules slow down the boot process

[William Cohen]

Jon Masters wrote:
> On Wed, 2008-04-02 at 00:23 -0400, Dave Jones wrote:
> 
> <snip comments about time taken in modprobe>
> 
>> Almost certainly a lot of it will be spent in parsing /lib/modules/$ver/modules.dep
>> Will Cohen did some experiments by sorting that file so that all the modules that
>> he had loaded were at the top of the file.  I forget the exact numbers, but
>> it made a noticable difference.

Here is a pointer to the previous measurements:

http://sources.redhat.com/ml/systemtap/2007-q1/msg00140.html

It was a couple second seconds, 1:07 vs 1:05 for boot time for a rawhide image 
mid Jan 2007.

-Will

> All I ever heard was that the maximum difference on boot time was a few
> seconds, and given the number of calls to modprobe being made by udev, I
> never really considered this a big problem. Kay didn't either because he
> built a udev with a minimal modprobe in it and found little difference.
> 
>> I suspect that if modules.dep was sorted and indexed, that lookups could be
>> made a lot faster than they are now.
> 
> However, this is probably worth doing. I'm also willing to consider the
> modprobed idea, though I think it'll be more useful to simply make
> modprobe part of a library that udev can simply link in directly. I'll
> start poking at the former idea (sorting modules.dep and indexing)
> first. Incidentally, in fact, we already sort those output files in
> RHEL, but that's more of a temporarily hack to make the loading order
> predictable when two conflicting PCI IDs are listed in those meta data.
> 
> On Wed, 2008-04-02 at 15:12 -0400, Bill Notting wrote:
> 
>> Kay started poking at integrating modprobe directly into udev with the
>> idea of solving some of this... IIRC it didn't help.
> 
> Yeah. It didn't. I'm all ears with regard to suggestions on ways to
> improve boot time, but let's first make sure we're 100% convinced where
> those problems are. Meanwhile, I'll take Dave's comments on board.
> 
> Jon.
> 
>