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: <ac3eb2510903020759j100adbdekf2067d142adbfbbe@mail.gmail.com>
Date:	Mon, 2 Mar 2009 16:59:17 +0100
From:	Kay Sievers <kay.sievers@...y.org>
To:	Andreas Robinson <andr345@...il.com>
Cc:	Rusty Russell <rusty@...tcorp.com.au>, sam@...nborg.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 0/6] module, kbuild: Faster boot with custom kernel.

On Mon, Mar 2, 2009 at 15:32, Andreas Robinson <andr345@...il.com> wrote:
> I have finished testing parallel module loading. It looks like a small
> kernel with a minimal initramfs and running several instances of insmod
> or modprobe in parallel has the best complexity to performance ratio.
>
> Testing shows that a megamodule is slightly slower than parallel
> insmods, so it's not really an option anymore.

That's what I expected, that we would need more changes, to make a
mega-module working, because we need parallel code execution here.

> A monolithic kernel with parallelized initcalls is better - about 200 ms
> faster than parallel insmods on my test system. However, it comes with a
> fairly large set of changes:
>
> * First, you need a 200-line patch in init/main.c (do_initcalls() and
> friends)
>
> * Then the built-in module dependencies must be calculated properly, eg
> with a modified depmod, and added to the build process.
>
> * Finally "soft" dependencies, i.e dependencies that are not implied by
> symbol use, have to be formalized and moved into the kernel somehow.
> Right now they're only defined in "install" commands in modprobe.conf.
>
> So, what do you think, should I keep going? IMHO, the slower userspace
> implementation is acceptable since it's so much simpler.

I think so too, and think we are fine using the current standard
tools. Also the recent modprobe changes make modprobe very fast by
using a binary index to resolve aliases. I think, we can leave the
stuff as it is.

Seems with the queued stop-machine()-removal patch, and possibly with
the minimized-mutex patch Rusty did, we are fine for now -- at least
with the current numbers, and from a distro's point of view.

Most of the "module load delay" distros see, are likely caused by I/O
loading the module from disk into the kernel, at least that's what my
profiles show. I did all the recent tests (which is a real world udev
coldplug) with a ramfs mount containing a copy of the module
directory, before running the module autoloader. I can link 40 modules
in 0.26 seconds into the kernel with the recent kernel patches.

Thanks for all your testing, it was really helpful, and your patches
have been the reason we've found the stop-machine problem. I'm glad
that we have real numbers now to point people to. It seems, that we
don't need to start fiddling around with hacks in userspace or
initramfs tools.

Thanks a lot,
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/