On Mon, Dec 22, 2014 at 1:04 PM, Lennart Poettering <lenn...@poettering.net> wrote: > 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. > > 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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
