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: <20090308090102.2db82a5b@infradead.org>
Date:	Sun, 8 Mar 2009 09:01:02 -0700
From:	Arjan van de Ven <arjan@...radead.org>
To:	Andreas Robinson <andr345@...il.com>
Cc:	Kay Sievers <kay.sievers@...y.org>,
	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 Sun, 08 Mar 2009 11:47:17 +0100
Andreas Robinson <andr345@...il.com> wrote:

> > but I guess that is for Ubuntu to resolve. I don't see the machines
> > I run (with Fedora) exhibit this same issue; while there are a
> > bunch of modules, none of the ones that are expensive-and-useless
> > in your charts are there.
> 
> I think they will. Fast boot is one of the "essential" goals for
> Jaunty and Karmic.
> 
> Anyway, attached is a bootchart for a cleaned up kernel with the
> important (AFAIK) drivers built in.

thanks; very useful overview!

> 
> >From this, I've found some tasks that I can set myself to. They would
> obviously be the topic of other threads:
> 
> * Make the nforce2 ethernet driver (init_nic) initialize itself
>   asynchronously, if possible.

I looked at doing this generically and it is really hard. BUT..
one of the options is to move work from the init to the "ifconfig up"
code...

In addition, for 2.6.30, I have a patch pending to move sata init
before the network init, which can help hide it some
> 
> * New config option: Separate initramfs decompression and
>   file-system calls. Decompress as early as possible in a
>   separate thread.

interesting idea!
> 
> * Don't unpack initramfs twice. If CONFIG_BLK_DEV_RAM is
>   set, the kernel decompresses the ramdisk just to see if
>   it's a cpio archive or not, and then throws away the result.

I actually have a patch for it stuck away somewhere; I thought it was
sent upstream but apparently it was not. I'll dig it out and dust it
off.

Note: Having a smaller initrd (like Fedora does, they make the initrd
only have the modules the specific machine needs) will save a bunch of
time... what isn't there you don't have to decompress either.

> 
> * See what can be done about pci_init(), if anything.
> 
> If there's anything else regarding fastboot you think would make more
> sense to work on first, please let me know.


One thing to mention is that fastinit for sata... I only did AHCI
(because all my machines have that). Your machine looks like it has
something different than AHCI, so maybe the sata controller can use
some work ;-)
(a sata driver needs to opt into parallel scanning via a flag)

SATA init tends to be one of the things that are fix time per drive;
and so working on that first to at least ONLY get that is worth it,
it's a huge chunk of time (more than half the total time in your
bootchart)


-- 
Arjan van de Ven 	Intel Open Source Technology Centre
For development, discussion and tips for power savings, 
visit http://www.lesswatts.org
--
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/