[systemd-devel] Improving module loading

Tom Gundersen teg at jklm.no
Sat Dec 20 07:56:54 PST 2014

On 16 Dec 2014 17:21, "Umut Tezduyar Lindskog" <umut at tezduyar.com> wrote:
> On Tue, Dec 16, 2014 at 4:59 PM, Tom Gundersen <teg at jklm.no> wrote:
> > On Tue, Dec 16, 2014 at 4:54 PM, Umut Tezduyar Lindskog
> > <umut at tezduyar.com> wrote:
> >> The other thought is, what is the preferred way of loading modules
> >> when they are needed.
> >
> > Rely on kernel autoloading. Not all modules support that yet, but most
> > do. What do you have in mind?
> We have some modules that we don't need them to be loaded so early. We
> much prefer them to be loaded when they are needed. For example we
> don't need to load the SD driver module until the service that uses SD
> driver is starting. With this idea in mind I started some
> investigation. Then I realized that our CPU utilization is not that
> high during module loading and I blame it to the sequential loading of
> modules. I am thinking this can be improved on systemd-modules-load
> side.

We can probably improve the module loading by making it use worker
processes similar to how udev works. In principle this could cause problems
with things making assumptions on the order of module loading, so that is
something to keep in mind. That said, note that most modules will be loaded
by udev which already does it in parallel...

> >> Do they have to be loaded on ExecStartPre= or as
> >> a separate service which has ExecStart that uses kmod to load them?
> >> Wouldn't it be useful to have something like ExecStartModule=?
> >
> > I'd much rather we improve the autoloading support...
> My understanding is autoloading support is loading a module if the
> hardware is available.

That, or for non-hardware modules when the functionally is first used
(networking, filesystems, ...).

> What I am after is though loading the module
> when they are needed.

This sounds really fragile to me (having to encode this dependency
everywhere rather than just always assume the functionality is available).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20141220/3d013c84/attachment-0001.html>

More information about the systemd-devel mailing list