First of all, a misconception: Upstart isn't about parallel boot. (This is from discussing a lot with the Upstart author at LPC)
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)
[Link]
Thanks a lot!
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 ;-)
LPC: Booting Linux in five seconds
Posted Sep 23, 2008 17:00 UTC (Tue) by s0f4r (guest, #52284)
[Link]
It's definately possible to approach the same boot speed with upstart. However, the overhead of reading all the upstart configuration files and doing all the parsing of those is still a bit higher than using plain sysvinit, hence we chose to use that.
This is not a weird choice: several netbook vendors currently do exactly the same thing for bootup.
LPC: Booting Linux in five seconds
Posted Sep 25, 2008 7:17 UTC (Thu) by aleXXX (subscriber, #2742)
[Link]
Now with all the multicore processors, parallelizing boot should indeed
bring a speedup, shouldn't it ?
Alex
LPC: Booting Linux in five seconds
Posted Sep 25, 2008 7:55 UTC (Thu) by dlang (✭ supporter ✭, #313)
[Link]
only if the bottleneck was CPU cycles.
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
LPC: Booting Linux in five seconds
Posted Sep 25, 2008 14:39 UTC (Thu) by arjan (subscriber, #36785)
[Link]
With multi-core or hyperthreading it is worth doing some things asynchronous.
But it's a subtle but important difference between doing things in parallel and doing some selected things asynchronous.
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.