very common kernel modules slow down the boot process
William Cohen
wcohen at redhat.com
Thu Apr 3 14:00:42 UTC 2008
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.
>
>
More information about the fedora-devel-list
mailing list