> -----Original Message-----
> From: Lennart Poettering [mailto:lenn...@poettering.net]
> Sent: Monday, December 22, 2014 4:05 PM
> To: Hoyer, Marko (ADITG/SW2)
> Cc: Umut Tezduyar Lindskog; systemd-devel@lists.freedesktop.org
> Subject: Re: [systemd-devel] Improving module loading
>
> On Sat, 20.12.14 10:45, Hoyer, Marko (ADITG/SW2) (mho...@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
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
