Not logged in
Log in now
Create an account
Subscribe to LWN
LWN.net Weekly Edition for May 23, 2013
An "enum" for Python 3
An unexpected perf feature
LWN.net Weekly Edition for May 16, 2013
A look at the PyPy 2.0 release
LPC: Booting Linux in five seconds
Posted Sep 23, 2008 7:20 UTC (Tue) by rvfh (subscriber, #31018)
Do you think it's possible to boot in 5 seconds with upstart 0.5 or a later version? Or is upstart (partly) going the wrong way?
Please enlighten us, or point us to a blog with your problems/decisions listed :-)
Posted Sep 23, 2008 8:46 UTC (Tue) by arjan (subscriber, #36785)
Second: Parallel boot is the wrong technology. It's a good answer to the "I want to boot faster" question, but it's absolutely the wrong answer to the "I want to boot fast" question. Eg it's something that gets you from 45 seconds to 43 seconds.... but not to 5. (note that Fedora 9 already uses Upstart.. and still boots in 45 seconds).
Parallel boot is the wrong thing; it ends up meaning that you're not really doing the critical path in sequential order; but let the system get distracted from that.
Asynchronous boot (where you let the critical path go sequential, and non-critical pieces asynchronous) is the right answer; the article has a graph about this. And Asynchronous boot you can do just fine with SysVinit.... no magic about that.
Posted Sep 23, 2008 9:57 UTC (Tue) by rvfh (subscriber, #31018)
I can't resist the desire to ask another question: I assume what you were told was that upstart was about event-driven starting/stopping of services, not parallelisation. Does it still make it possible to implement this 5-seconds boot with upstart? Or does upstart get, somehow, in the way?
Thanks for the _very_ useful job you did: some of us still need to boot their machine sometimes ;-)
Posted Sep 23, 2008 17:00 UTC (Tue) by s0f4r (subscriber, #52284)
This is not a weird choice: several netbook vendors currently do exactly the same thing for bootup.
Posted Sep 25, 2008 7:17 UTC (Thu) by aleXXX (subscriber, #2742)
Posted Sep 25, 2008 7:55 UTC (Thu) by dlang (✭ supporter ✭, #313)
and most of the time it's not.
you have serialization on a lot of things
disk I/O (reading files, searching for the 50 places a config file could be before you find the one where it is, etc)
bus access (you can't query a PCI bus for multiple things at the same time)
timeouts (waiting after sending a command to see if something responds).
timeouts frequently combine with bus access as it may not be safe to do something else until you get a response from the device you just probed for (or decide that it's not really there)
and sometimes you do really have number crunching CPU tasks to do.
multi-core systems make a big difference if you really do have CPU as the limiting factor, but that's usually not the case (and IMHO software that has to do a lot of cpu work to just start up is probably in need of being fixed)
yes, when you get down into the low single-digit bootup range on a relativly slow COU (like the eepc from the talk), you do have to pay attention to the CPU load, but if you have similar systems otherwise, a fast cpu doesn't make that big a difference on a normal distro bootup
Posted Sep 25, 2008 14:39 UTC (Thu) by arjan (subscriber, #36785)
The key thing is to do the "critical path" of the boot sequential and as tightly packed as possible, while doing non-critical (to the boot) things asynchronous.
Posted Sep 23, 2008 20:19 UTC (Tue) by mezcalero (subscriber, #45103)
It's nice to be able to boot in 5s, but this is far from a standard Fedora system. Be honest!
Posted Sep 23, 2008 20:27 UTC (Tue) by rlk (guest, #47505)
Posted Sep 23, 2008 21:30 UTC (Tue) by nix (subscriber, #2304)
(How many people not using laptops have multiple printers anyway? Is it
really common outside offices?)
Posted Sep 23, 2008 22:02 UTC (Tue) by foom (subscriber, #14868)
Posted Sep 25, 2008 15:39 UTC (Thu) by msmeissn (subscriber, #13641)
And it manages local queues occasionaly, which was one reason I heard to
have it run all the time. (Not sure if this applies.)
Posted Sep 27, 2008 15:27 UTC (Sat) by keybuk (subscriber, #18473)
Starting CUPS on demand isn't quite ideal sadly, if the user is using
network printers, then CUPS needs to have already been running for about
30s before they try and print otherwise the network printer won't be shown.
Sadly we can't "start CUPS 30s before the user needs it" ;)
Though I entirely agree in principle that CUPS is not part of the critical
path of the boot sequence, if the system is idle at some point, it's worth
starting -- even if that means the disk isn't entirely inactive after boot.
The most ideal way to deal with these kinds of services is to start them
after boot, when the system is idle - with low CPU and I/O scheduler
priority so that user activity takes precedence - or activate them on
demand by xinetd or D-Bus when the user actually needs them.
That way, if the user clicks print and cups wasn't running yet, it gets
brought up -- or if the user leaves their PC alone for a bit, we start cups
for the next time they click print.
Of course, even better would be if we could do network printer discovery
via other means like Avahi -- but then Avahi falls into the exact same
"start on idle or first demand, whichever is sooner" category
Posted Oct 2, 2008 8:36 UTC (Thu) by renox (subscriber, #23785)
2) users are unlikely to print just after starting the computer so launching the desktop before CUPS is okay.
3) the critical part for the user here is the 'time to print' if having to find a network printer really slow downs printing then it make sense to have CUPS running all the time, not on demand.
Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds