|
|
Subscribe / Log in / New account

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

Different people need different things for a "full system". I don't need Bluetooth at all and Avahi isn't really terribly valuable to me, either (I'm in a pure UNIX/Linux environment where I don't need to worry about file sharing, and otherwise I have a fairly static environment most of the time). I do need CUPS but it's fine if it takes 10-30 seconds more to start; I'm not likely to print as the very first thing I do after boot.


to post comments

LPC: Booting Linux in five seconds

Posted Sep 23, 2008 2:01 UTC (Tue) by arjan (subscriber, #36785) [Link] (14 responses)

We have cups starting from xinetd... on demand

LPC: Booting Linux in five seconds

Posted Sep 23, 2008 7:20 UTC (Tue) by rvfh (guest, #31018) [Link] (6 responses)

Could you tell us why Sys V init was prefered to upstart? Shouldn't upstart replace xinetd _and_ init _and_ provide faster boot through parallelisation?

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 :-)

LPC: Booting Linux in five seconds

Posted Sep 23, 2008 8:46 UTC (Tue) by arjan (subscriber, #36785) [Link] (5 responses)

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.

LPC: Booting Linux in five seconds

Posted Sep 23, 2008 9:57 UTC (Tue) by rvfh (guest, #31018) [Link] (1 responses)

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] (2 responses)

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 (guest, #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.

LPC: Booting Linux in five seconds

Posted Sep 23, 2008 20:19 UTC (Tue) by mezcalero (subscriber, #45103) [Link] (3 responses)

That doesn't really work. CUPS without the browsing is not really useful. And for the browsing you need to run it continuously all the time. Much like Avahi.

It's nice to be able to boot in 5s, but this is far from a standard Fedora system. Be honest!

LPC: Booting Linux in five seconds

Posted Sep 23, 2008 20:27 UTC (Tue) by rlk (guest, #47505) [Link] (1 responses)

As I said before, not everyone needs browsing -- a lot of people are in more or less static environments where the topology never changes. There's no reason why those people should be burdened by the overhead of network browsing.

LPC: Booting Linux in five seconds

Posted Sep 23, 2008 21:30 UTC (Tue) by nix (subscriber, #2304) [Link]

Exactly. I have one printer, and it's connected to one machine. Why do I
need browsing?

(How many people not using laptops have multiple printers anyway? Is it
really common outside offices?)

LPC: Booting Linux in five seconds

Posted Sep 23, 2008 22:02 UTC (Tue) by foom (subscriber, #14868) [Link]

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

Posted Sep 25, 2008 15:39 UTC (Thu) by msmeissn (subscriber, #13641) [Link]

CUPS does printer autodiscovery (zeroconf style, but on other ports), so
some people want it running to find printers. :/

And it manages local queues occasionaly, which was one reason I heard to
have it run all the time. (Not sure if this applies.)

Ciao, Marcus

LPC: Booting Linux in five seconds

Posted Sep 27, 2008 15:27 UTC (Sat) by keybuk (guest, #18473) [Link] (1 responses)

Although according to your boot chart, you're not starting xinetd either ;)

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

LPC: Booting Linux in five seconds

Posted Oct 2, 2008 8:36 UTC (Thu) by renox (guest, #23785) [Link]

Agreed, I understand the desire to do 'booting in 5s' without cheating, but CUPS is probably one exception here where cheating is okay:
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.

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 © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds