[systemd-devel] Improving module loading

[Umut Tezduyar Lindskog]

Hi Marko,

Thank you very much for your feedback!

On Sat, Dec 20, 2014 at 11:45 AM, Hoyer, Marko (ADITG/SW2)
<mhoyer at de.adit-jv.com> wrote:
> Hi,
>
>> -----Original Message-----
>> From: systemd-devel [mailto:systemd-devel-
>> bounces at lists.freedesktop.org] On Behalf Of Umut Tezduyar Lindskog
>> Sent: Tuesday, December 16, 2014 4:55 PM
>> To: systemd-devel at 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:

Do you have links for the discussions, I cannot find them. systemd
already has a service that loads the modules.

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

We are aware of the potential complications and races. But good to be
reminded :)

Umut

>
>>
>> Umut
>> _______________________________________________
>> systemd-devel mailing list
>> systemd-devel at 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
>