[systemd-devel] Improving module loading

[Lucas De Marchi]

On Mon, Dec 22, 2014 at 1:04 PM, Lennart Poettering
<lennart at poettering.net> wrote:
> 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.
>
> 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.

I'm skeptical you would get any speed up for that. I think it would be
better to have some numbers shared before merging such a thing.

If you have 1 context per module/thread you will need to initialize
each context which is really the most expensive part in userspace,
particularly if finit_module() is being used (which you should unless
you have restrictions on the physical size taken by the modules). Bare
in mind the udev logic has only 1 context, so the initialization is
amortized among the multiple module load calls.

For the "don't load until it's needed" I very much prefer the static
nodes approach we have. Shouldn't this be used instead of filling
modules-load-d with lots of entries?

I really miss numbers here and more information on which modules are
taking long because they are serialized.

-- 
Lucas De Marchi