[lkml]   [2009]   [Feb]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.
On Wednesday 18 February 2009 19:45:21 Kay Sievers wrote:
> On Wed, Feb 18, 2009 at 05:58, Rusty Russell <> wrote:
> > On Tuesday 17 February 2009 22:23:25 Kay Sievers wrote:
> >> Monolithic versus modular kernels usually
> >> make about 2+ seconds difference on a recent laptop.
> >
> > Thanks for the fact injection. How about a megamodule then?
> Sounds interesting. The ability to load multiple modules with a single
> call may help, if such a call could be handled faster than individual
> calls. Modprobe's modules added by dependencies of the requested
> module, or modprobe -a could probably use such a facility.

Naah, just create the megamodule in userspace. It's not terribly hard:
you create a new init which calls all the individual inits, and rename
the module. You don't supply an "exit" so it can't be unloaded, and for
bonus points remove the .exit sections which will never be used.

I'm handwaving a little, but it would get you all the benefits with no
kernel changes.

Andreas is definitely capable of creating such a thing: it's easier than
what he did with linking in modules!

> The current load_module() wraps ~400 lines of pretty heavy code in
> stop_machine(), if we could possibly make that window smaller, so that
> multiple instances could prepare some of the work in parallel, and
> only a fraction of the current work would need to be serialized?

Module load doesn't use stop_machine (on non-error). I'm not sure where the code is spending time. We could shuffle things around so most of load_module doesn't run under the lock, but before that can you tell me if we still lose 2-3 seconds on a UP kernel?

If so, it's not locking, I'd guess it's probably modprobe userspace and reading in the modules from disk, not sys_init_module at all.


 \ /
  Last update: 2009-02-18 12:59    [W:0.196 / U:13.808 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site