[systemd-devel] Improving module loading

[Hoyer, Marko (ADITG/SW2)]

> -----Original Message-----
> From: Greg KH [mailto:gregkh at linuxfoundation.org]
> Sent: Saturday, December 20, 2014 6:11 PM
> To: Hoyer, Marko (ADITG/SW2)
> Cc: Umut Tezduyar Lindskog; systemd-devel at 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-
> > > 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).
> 
> 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