[Debian-eeepc-devel] 5 second boot
Phil Endecott
spam_from_debian_eee at chezphil.org
Sat Oct 11 22:45:06 UTC 2008
Daniel Moerner wrote:
>> They have used something called sReadAhead to prefetch the required
>> blocks from the disk. Hopefully this can be packaged for Debian.
>
> The code is available, sans documentation, here:
> http://www.moblin.org/downloads/super-read-ahead-002
>
> I made a post asking about clarification of the usage (when do you run
> generate_filelist? How do you actually use the program?) but haven't
> gotten a response. It seems a bit different from standard readahead,
> and has a kernel patch to go with it.
John Lamb has now posted a recipe for Debian on that page. He doesn't
seem to use the kernel patch so we still don't know what that does.
I've tried it, and it does seem to basically work in as much as I have
fewer disk access peaks in the bootchart output than I did before. But
I do still have one huge peak from fsck (is that right?), and the
improvement in boot time is small to immeasurable.
Other things to look at:
- Now that I have built pciehp into the kernel (and note that you need
to add a kernel command line option pciehp.pciehp_force=1 to make this
do the right thing), I can see that this wastes a couple of seconds
while it is starting.
- udev takes a while, presumably mostly creating /dev nodes. As I
understand it, Arjan & Aoke do start udev at the end of boot to handle
hotplugged devices. So is it possible to pre-populate /dev with nodes
saved from a previous boot and then not run "udevadm trigger"? (Are
the device major/minor numbers consistent?) What happens if I plug in
a USB device while the machine is off? I do wonder whether the correct
solution to this is actually to look at the udevd source and work out
why it's slow.
- It seems that the hardware clock is accessed twice (hwclock and
hwclockfirst I think); why? And why does each take about a second? Is
this a consequence of the --directisa hack?
Cheers, Phil.
More information about the Debian-eeepc-devel
mailing list