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: <1235216636.7025.1023.camel@andreas-laptop>
Date:	Sat, 21 Feb 2009 12:43:56 +0100
From:	Andreas Robinson <andr345@...il.com>
To:	Kay Sievers <kay.sievers@...y.org>
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 Fri, 2009-02-20 at 02:55 +0100, Kay Sievers wrote:
> On Fri, Feb 20, 2009 at 01:37, Andreas Robinson <andr345@...il.com> wrote:

[...]

> > So, what's missing or been done wrong here? I expected the difference
> > between monolithic and modular to be greater to be honest.
> 
> How do you compare the monolithic kernel? What are the 6.27 seconds
> here? The time to boot into /sbin/init without any module load?

It is a wall-time comparison testing how long it takes until all drivers
are initialized.

The last driver to be initialized is a dummy module that merely prints a
timestamp in its init function. That's where the 6.27 seconds come from.

So, the initramfs should have no impact on the monolithic case as it is
not accessed until after the initcalls.

> I wouldn't be surprised if you just wait in the kernel for some
> hardware, driven by a built-in module, to init. Do you use current git
> and the "fastboot" commandline option?

Current git, yes. Fastboot, no, I didn't know it existed! Adding
fastboot, there are dramatic improvements; monolithic boot time is now
3.08 seconds, megamodule is 3.37 and insmod list 3.85. So you are right
to not be surprised. :)

> I don't think the megamodule will help us much, unless we change the
> kernel to parallelize something here, or save some other overhead. It
> should not be different from the serial insmods, if the data is not
> sprinkled over the disk, which an initramfs isn't. And the
> fragmentation problem should not be solved with a mega-module. :)
> 
> The general problem is that todays distros start like 100 modprobes in
> 2 seconds, which does not really compare to a sequential insmod test.
> 
> I'm pretty sure, for real-world numbers we need to load them in
> parallel, and look at the kernel side, if we can minimize the locked
> code area, so we can do as much as possible in parallel.
> 
> Only if that is addressed, I think, we can get useful numbers how much
> time we really spend in in-kernel linking and can start evaluating if
> pre-linking modules would make sense, or not.

Understood. I will parallelize things, add Rusty's patch and see where
we end up!

Cheers,
Andreas

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