> -----Original Message-----
> From: systemd-devel [mailto:systemd-devel-
> boun...@lists.freedesktop.org] On Behalf Of Umut Tezduyar Lindskog
> Sent: Tuesday, December 16, 2014 4:55 PM
> To: systemd-devel@lists.freedesktop.org
> Subject: [systemd-devel] Improving module loading
> Hi,
> Is there a reason why systemd-modules-load is loading modules
> sequentially? Few things can happen simultaneously like resolving the
> symbols etc. Seems like modules_mutex is common on module loads which
> gets locked up on few occasions throughout the execution of
> sys_init_module.

We are actually doing this (in embedded systems which need to be up very fast 
with limited resources) and gained a lot. Mainly, IO and CPU can be better 
utilized by loading modules in parallel (one module is loaded while another one 
probes for hardware or is doing memory initialization).

> The other thought is, what is the preferred way of loading modules when
> they are needed. 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 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.

Btw: Be careful with synchronization. We found that lots of kernel modules are 
exporting device nodes in the background (alsa, some graphics driver, ...). 
With the proceeding mentioned above, you are moving the kernel module loading 
and the actual use of the driver interface very close together in time. This 
might lead to race conditions. It is even worse when you need to access sys 
attributes, which are exported by some drivers even after the device is already 
available and uevents have been sent out. For such modules, there actually is 
no other way for synchronization but waiting for the attributes to appear.

> Umut
> _______________________________________________
> systemd-devel mailing list
> systemd-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Best regards

Marko Hoyer
Software Group II (ADITG/SW2)

Tel. +49 5121 49 6948

systemd-devel mailing list

Reply via email to