[systemd-devel] Improving module loading

[Hoyer, Marko (ADITG/SW2)]

> -----Original Message-----
> From: systemd-devel [mailto:systemd-devel-
> bounces at lists.freedesktop.org] On Behalf Of Tom Gundersen
> Sent: Saturday, December 20, 2014 4:57 PM
> To: Umut Tezduyar
> Cc: systemd Mailing List
> Subject: Re: [systemd-devel] Improving module loading
> 
> 
> 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.

We realized it with threads, which are much cheaper for this job.

> In principle this could cause
> problems with things making assumptions on the order of module loading,
> so that is something to keep in mind.

Mmm, I don't see any issues here since the dependencies are normally properly described on kernel side (otherwise you have a problem in any case). In worst case you are losing potential to parallelize loading of modules if your algorithm for distributing the modules to workers is not working efficiently.

> That said, note that most modules
> will be loaded by udev which already does it in parallel...

... only if you are still triggering "add" uevent through the complete device tree during startup, which is really expensive and does not go with the "load things not before they are actually needed" philosophy very well ...

> 
> > >> 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).

That is actually the main challenge when this approach is applied. But the assumption you are talking about is in many cases a kind of facade only at least if your applications
- are not waiting for udev to completely settle after the coldplug trigger, or
- are able to deal with devices in a hotplug fashion.

> 
> Cheers,
> 
> Tom


Best regards

Marko Hoyer
Software Group II (ADITG/SW2)

Tel. +49 5121 49 6948