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]

Date:	Wed, 18 Feb 2009 14:57:58 +0100
From:	Kay Sievers <kay.sievers@...y.org>
To:	Rusty Russell <rusty@...tcorp.com.au>
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 Wed, Feb 18, 2009 at 12:57, Rusty Russell <rusty@...tcorp.com.au> wrote:
> On Wednesday 18 February 2009 19:45:21 Kay Sievers wrote:

>> 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 see, right. It's only the mutex serializing all module loading work.

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

I tried only my dual core laptop with my "small" kernel and 50
modules, not the crazy distro setup.

I've added stuff like:
   ktime_t in, delta;
   unsigned long long duration;

   in = ktime_get();

   ...

   delta = ktime_sub(ktime_get(), in);
   duration = (unsigned long long) delta.tv64 >> 10;
   printk("XXX: loading %p (%Ld usecs)\n", umod, duration);

across init_module() and some modules wait for 200-500 milliseconds to
get the lock released, some larger modules spend 50 milliseconds in
load_module(), many of them around 20 milliseconds.

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

Bootcharts suggest that it's not I/O bound. We also see this on fast
SSDs and with pre-loading files into RAM. Older modprobe versions did
some heavy fnmatch() over an insanely large distro module.alias file,
which was very CPU expensive, but that got changed recently.

Thanks,
Kay
--
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/