LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
Posted Sep 23, 2008 0:19 UTC (Tue) by rlk (guest, #47505)In reply to: LPC: Booting Linux in five seconds by mezcalero
Parent article: LPC: Booting Linux in five seconds
Posted Sep 23, 2008 2:01 UTC (Tue)
by arjan (subscriber, #36785)
[Link] (14 responses)
Posted Sep 23, 2008 7:20 UTC (Tue)
by rvfh (guest, #31018)
[Link] (6 responses)
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)
[Link] (5 responses)
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 (guest, #31018)
[Link] (1 responses)
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 (guest, #52284)
[Link]
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)
[Link] (2 responses)
Alex
Posted Sep 25, 2008 7:55 UTC (Thu)
by dlang (guest, #313)
[Link]
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)
[Link]
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)
[Link] (3 responses)
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)
[Link] (1 responses)
Posted Sep 23, 2008 21:30 UTC (Tue)
by nix (subscriber, #2304)
[Link]
(How many people not using laptops have multiple printers anyway? Is it
Posted Sep 23, 2008 22:02 UTC (Tue)
by foom (subscriber, #14868)
[Link]
Posted Sep 25, 2008 15:39 UTC (Thu)
by msmeissn (subscriber, #13641)
[Link]
And it manages local queues occasionaly, which was one reason I heard to
Ciao, Marcus
Posted Sep 27, 2008 15:27 UTC (Sat)
by keybuk (guest, #18473)
[Link] (1 responses)
Starting CUPS on demand isn't quite ideal sadly, if the user is using
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
The most ideal way to deal with these kinds of services is to start them
That way, if the user clicks print and cups wasn't running yet, it gets
Of course, even better would be if we could do network printer discovery
Posted Oct 2, 2008 8:36 UTC (Thu)
by renox (guest, #23785)
[Link]
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.
LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
bring a speedup, shouldn't it ?
LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
But it's a subtle but important difference between doing things in parallel and doing some selected things asynchronous.
LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
need browsing?
really common outside offices?)
Actually, modern Cups actually uses dns-sd for printer discovery instead of special broadcast
messages, so it no longer needs to be continuously running to receive the broadcasts: avahi will
handily take care of that part. Yay consolidation.
LPC: Booting Linux in five seconds
LPC: Booting Linux in five seconds
some people want it running to find printers. :/
have it run all the time. (Not sure if this applies.)
LPC: Booting Linux in five seconds
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.
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.
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.
brought up -- or if the user leaves their PC alone for a bit, we start cups
for the next time they click print.
via other means like Avahi -- but then Avahi falls into the exact same
"start on idle or first demand, whichever is sooner" category
LPC: Booting Linux in five seconds
1) it's unlikely to take much CPU or IO load (if it does then it's a bug) so starting it in the background won't be felt as a slowdown for the user.