[systemd-devel] Improving module loading

[Greg KH]

On Sun, Dec 21, 2014 at 12:31:30PM +0000, Hoyer, Marko (ADITG/SW2) wrote:
> > 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.

What do you mean by this?  What is limiting this?  What is your limit?
How large are these kernel modules that you are having a hard time to
build into your kernel image?

> - Loading the image is a kind of monolithic block in terms of time where you can hardly do things in parallel

How long does loading a tiny kernel image actually take?

> - 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)

Ah, IVI, you all have some really strange hardware configurations :(

There is no reason you have to do a "cold reset" to get your boot times
down, there is the fun "resume from a system image" solution that others
have done that can get that camera up and displayed in milliseconds.

> - Some modules do time / CPU consuming things in init(), which would delay the entry time into userspace

Then fix them, that's the best thing about Linux, you have the source to
not accept problems like this!  And no module should do expensive things
in init(), we have been fixing issues like that for a while now.

> 	-> deferred init calls are not really a solution because they cannot be controlled in the needed granularity

We have loads of granularity there, how much more do you need?

> 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.

That's fine, but you will run into the kernel lock that prevents modules
loading at the same time for some critical sections, if your I/O issues
don't limit you already.

There are lots of areas you can work on to speed up boot times other
than worrying about multithreaded kernel module loading.  I really doubt
this is going to be the final solution for your problems.

good luck,

greg k-h