linux-kernel - Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <200902182227.14686.rusty@rustcorp.com.au>
Date:	Wed, 18 Feb 2009 22:27:14 +1030
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Kay Sievers <kay.sievers@...y.org>
Cc:	Andreas Robinson <andr345@...il.com>, sam@...nborg.org,
	linux-kernel@...r.kernel.org, Jon Masters <jonathan@...masters.org>
Subject: Re: [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 <rusty@...tcorp.com.au> 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.

Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/