[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Boot poster challenge

On Sat, 2004-11-13 at 18:35 +0100, Arjan van de Ven wrote:
> On Sat, 2004-11-13 at 12:18 -0500, Owen Taylor wrote:
> > Ideally, system boot would involve a 3-4 second sequential read of
> > around 100 megabytes of data from the hard disk,
> make that 7 seconds..
> Note: I did this experiment about a year ago, during boot first read
> everything into cache and then do the rest of boot basically without
> disk IO (there are some writes but that's async).
> The total time to boot did not decrease ......

That experiment was one of the things that convinced me that getting
a good visualization of the critical path is crucial to actually 
speeding up the boot process.

> >  CPU utilization would
> > be parallelized with that, and all queries on external systems would
> > be asynchronous ... startup continues and once the external system
> > responds, the system state is updated. Plausibly the user could start
> > work under 10 seconds on this ideal system.
> given the 7 second disk read time... 10 seconds is a bit unrealistic.
> One of the critical paths will be getting an IP address and mounting the
> /home dir over nfs... ethernet negotiation can easily be 10 seconds
> already with gige, and DHCP is depending on that to complete before it
> can get a lease.

I'd agree 10 seconds isn't a realistic target; my point was more that
if we have only 7 seconds of disk access, and, say, 10 seconds of 
computation to do, and maybe 15 seconds too negotiate gige, get a 
dhcp lease, and mount your homedir (if relevant), then the time 
between 15 seconds and 2 minutes needs to be investigated in terms
of dependencies.

> One of the things we should investigate is just reduce the shere number
> of different files that get opened.... its about 11000 iirc right now.

If we're actually spending all our time waiting on a DHCP lease, or 
for probing serial mice to timeout, then 11000 opens don't matter a
whole lot. Not that eliminating the opens isn't a good idea...


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]