Paralell startup

[Michael Wiktowy]

>Date: Wed, 20 Oct 2004 10:53:17 -0400
>From: Arjan van de Ven <arjanv at redhat.com>
>Subject: Re: Paralell startup
>
>On Tue, 2004-10-19 at 12:10, Kyrre Ness Sjobak wrote:
>  
>
>>> I am hearing much good from the gentoo camp about paralell startup, and
>>> how it brings down boot times to about 30 secounds. Is this possible to
>>> do with fedora as well?
>>    
>>
> problem with parallel startup is that it *ALSO* increases how much the 
> disk has to seek, which slows things down. For me it's not clear if 
> it's actually a real gain or just a placebo one.


You are right ... just starting up everything that can possibly be 
started up all at once makes no sense since it will undoubtedly add 
overhead above and beyond the time for each to start separately.

There are some situations/landmarks that are independant of disk access 
though.
I would break things up into three phases of booting:
1) Hardware detection and configuration - pretty much everything has to 
wait for this (and all the HAL/hotplug/udev stuff is looking really 
slick, BTW)
2) Network connection - there are going to be many things that need to 
wait for a network interface to be established but many others that 
couldn't care less and could continue on loading up without waiting for 
slow DHCP resolution or a bit long timeout before ifup failure (both 
things catch me on a regular basis).
3) X server startup and presentation of GUI login - this could be 
spawned quite early on while everything else keeps loading in the 
background. Psychologically, many people believe that the boot is done 
when they can interact with the machine. Windows uses this trick 
extensively. While it looks like it has booted, try opening up an app 
... it takes *ages* until it has truly finished loading everything in 
the background.

Each of these milestones can "fork" off a parallel ordered branch of 
startup scripts which may _seem_ to start up faster and avoid big pauses 
when there is trouble. It shouldn't add too much complication to the 
init. Each script just has to identify whether it needs networking to be 
up or if it blocks X.

/Mike