> -----Original Message----- > From: Greg KH [mailto:gre...@linuxfoundation.org] > Sent: Saturday, December 20, 2014 6:11 PM > To: Hoyer, Marko (ADITG/SW2) > Cc: Umut Tezduyar Lindskog; systemd-devel@lists.freedesktop.org > Subject: Re: [systemd-devel] Improving module loading > > On Sat, Dec 20, 2014 at 10:45:34AM +0000, Hoyer, Marko (ADITG/SW2) > wrote: > > Hi, > > > > > -----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). > > If you have control over your kernel, why not just build the modules > into the kernel, then all of this isn't an issue at all and there is no > overhead of module loading?
It is a questions of kernel image size and startup performance. - We are somehow limited in terms of size from where we are loading the kernel. - Loading the image is a kind of monolithic block in terms of time where you can hardly do things in parallel - We are strongly following the idea from Umut (loading things not before they are actually needed) to get up early services very early (e.g. rendering a camera on a display in less than 2secs after power on) - Some modules do time / CPU consuming things in init(), which would delay the entry time into userspace -> deferred init calls are not really a solution because they cannot be controlled in the needed granularity So finally it is actually a trade of between compiling things in and spending the overhead of module loading to gain the flexibility to load things later. > > greg k-h 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