[systemd-devel] Improving module loading

Hoyer, Marko (ADITG/SW2) mhoyer at de.adit-jv.com
Tue Dec 23 03:53:01 PST 2014

> -----Original Message-----
> From: Lennart Poettering [mailto:lennart at poettering.net]
> Sent: Monday, December 22, 2014 4:05 PM
> To: Hoyer, Marko (ADITG/SW2)
> Cc: Umut Tezduyar Lindskog; systemd-devel at lists.freedesktop.org
> Subject: Re: [systemd-devel] Improving module loading
> On Sat, 20.12.14 10:45, Hoyer, Marko (ADITG/SW2) (mhoyer at de.adit-
> jv.com) wrote:
> > I had such a discussion earlier with some of the systemd guys. My
> > intention was to introduce an additional unit for module loading for
> > exactly the reason you mentioned. The following (reasonable) outcome
> > was:
> >
> > - It is dangerous to load kernel modules from PID 1 since module
> >   loading can get stuck
> > - Since modules are actually loaded with the thread that calls the
> >   syscall, systemd would need additional threads
> > - Multi Threading is not really aimed in systemd for stability
> reasons
> >
> > The probably safest way to do what you intended is to use an
> > additional process to load your modules, which could be easily done
> by
> > using ExecStartPre= in a service file. We are doing it exactly this
> > way not with kmod but with a tool that loads modules in parallel.
> I'd be willing to merge a good patch that beefs up systemd-modules-load
> to load the specified modules in parallel, with one thread for each.

Ok, I'll take this into my company. I've to find out if and how it is possible to cut out pieces from our software and to provide a patch for systemd-modules-load. Maybe we could go open source with the complete tool. I've to find out ...

> We already have a very limited number of threaded bits in systemd, and
> I figure out would be OK to do that for this too.
> Please keep the threading minimal though, i.e. one kmod context per
> thread, so that we need no synchronization and no locking. One thread
> per module, i.e. no worker thread logic with thread reusing. also,
> please set a thred name, so that hanging module loading only hang one
> specific thread and the backtrace shows which module is at fault.

- we are actually using one kmod context for all modules in all threads
	- the main thread (kind of control thread) is doing most of the stuff with the context (querying, resolving dependencies, ...)
	- The worker threads are doing only one call: kmod_module_insert_module(kmodule->mod,0,kmodule->mod_params)
	- I took a look into the implementation of this function and did not find so much dangerous stuff in it
	- If it would make feel people safer, I could create different contexts for the worker threads
- and actually, we are using a fixed pool of worker threads receiving jobs from the main thread ;) Synchronization is done via eventfd.

I guess it would be best if we would take a look into our stuff once we are sure that we are able to contribute the stuff and that this stuff is actually wanted. We can then surely do some rework based on your experience.

> Lennart
> --
> Lennart Poettering, Red Hat

Best regards

Marko Hoyer
Software Group II (ADITG/SW2)

Tel. +49 5121 49 6948

More information about the systemd-devel mailing list