Ответ: MODPROBE: next generation

Vladimir Dronnikov dronnikov at gmail.com
Sun Jul 6 07:38:26 UTC 2008


Understood. Well done!

The only spiky edge I see in the following. At system startup when
udevtrigger is called (or another technique of populating /dev is
used) a lot of modprobes is called in parallel and they all have no
plain module name specified. So they all need to go the most
time-consuming branch of code: to read and parse on average the half
of all modules. And the gain can be microscopic considering the growth
in size.

The ordinary use of modprobe after system has started up is not so
time critical IMO. Is it?

I propose to use intermediate dependencies storage (see the last
patch). That way the very first modprobe will cache all dependencies
once, so others will work very fast. The only problem is to block
concurrent modprobes until the first is done (semaphores?). The
fallback (say, when filesystem is RO) may result in just skipping of
storage creating.

--
Vladimir


2008/7/6, Denys Vlasenko <vda.linux at googlemail.com>:
> [CC: busybox at busybox.net]
>
> On Sunday 06 July 2008 08:27, Vladimir Dronnikov wrote:
>> Hello, Denys!
>>
>> Looked through modutils-small.c. Could you explain the changes you
>> made? I see the code became >500 bytes larger...
>
> I made the following changes:
>
> * directory scannig is done just once
> * if we find module to modprobe during dirscan, we immediately
>   try to load it. If it succeeds, we exit. This makes modprobe
>   MUCH faster in some quite coomon cases.
> * otherwise, we remember all module pathnames, so that we
>   do not need to scan directory again.
> * If module was found but failed to load, we read ONLY that
>   module's body, determine deps, scan in-memory list of modules,
>   and try to load deps (recursively doing the same
>   "read body, find deps" for each of them).
> * ONLY if module was not found by name, we read ALL module
>   bodies and find alias names. Very time consuming.
>   Still, as soon as alias is found, the module body reading
>   stops (cuts time down by 50% on average).
>   Then we try to load found module as above.
>
> I decided to get the above logic working correctly so that
> modprobe wouldn't scan whole module directory, and read
> each and every module in it on every call; and turn
> my attention to shrinking it later.
> --
> vda
>



More information about the busybox mailing list