Linked by diegocg on Sun 13th May 2012 23:48 UTC
Linux Lennart Poettering, the author of systemd, has announced: "I just put a first version of a wiki document together that lists a couple of easy optimizations to get your boot times down to [less than] 2s. It also includes a list of suggested things to hack on to get even quicker boot-ups."
Thread beginning with comment 517979
To read all comments associated with this story, please click here.
As a kernel dev myself
by Alfman on Mon 14th May 2012 02:34 UTC
Alfman
Member since:
2011-01-28

I've always found it bewildering how long so many commercial operating systems take to bootup.

The following bottlenecks probably deserve most of the blame:

1. Unnecessary Serialization.
Most devices are independent from one another and can be initialized at the same time, but many coders are lazy or not good at multitheaded/multiprocess programming and depend on critical sections, disabling interrupts, etc. Even drivers which support parallel execution might be prevented from doing so by the OS. Several linux distros suffer huge performance penalty because their init scripts load everything serially instead of in parallel.

2. Unnecessary delays.
I've seen this so often it makes me disappointed in my peers, but they often solve race conditions by adding arbitrary delays throughout the code. For example back in the modem days it was very common to see companies running code that delays between AT commands and even some cases where the code had hard coded delays between characters. These delays will become significantly less optimal as hardware evolves. One company thought they were being clever and made the delays configurable - how thoughtful. Removing these delays means solving race conditions that the original developer couldn't be bothered to solve.


3. Disk thrashing.
This one is easy enough to fix by using a SSD. For HDs, placing everything in an initd and/or rearranging startup apps linearly on disk will significantly reduce the need for numerous and slow disk seek operations. I've seen defrag tools do this for windows, but I've never seen anything similar for linux (can someone clue me in!).

(4. Network delay)
I hesitate to add this one, since an unresponsive network should not really cause local bootup delays. But in fact I have seen cases of it where serially loaded processes get blocked due to a process waiting on DHCP or a network connection.

Reply Score: 3

RE: As a kernel dev myself
by ssokolow on Mon 14th May 2012 02:54 in reply to "As a kernel dev myself"
ssokolow Member since:
2010-01-21

(4. Network delay)
I hesitate to add this one, since an unresponsive network should not really cause local bootup delays. But in fact I have seen cases of it where serially loaded processes get blocked due to a process waiting on DHCP or a network connection.


I've also occasionally run into parallel loading where neither the developers nor the system were smart enough to take prior boots into account, so the network init got done late enough that, before the network init finished, the init system had started to run out of tasks which could be run in parallel without waiting for the network to be up.

Reply Parent Score: 2

RE[2]: As a kernel dev myself
by Alfman on Mon 14th May 2012 04:52 in reply to "RE: As a kernel dev myself"
Alfman Member since:
2011-01-28

ssokolow,

Yea exactly.

The system will become idle while waiting for the network to come up, and then when it does it gets busy loading again. Ideally the loading would never stop/block until everything is fully loaded, even if the network isn't ready.


The problem can be more complex than meets the eye, since many daemons will fail when they call bind & listen if the network isn't up yet. Existing standards lack a way to have these processes load all their resources prior to the network becoming available. They'd probably need to poll for the network, which would only make the problem worse.


I did the following tests:


Terminal A

ifconfig br0:1 down
socat TCP-LISTEN:5555,bind=192.168.100.52 -
// above fails because network IP not yet available

ifconfig br0:1 192.168.100.52
socat TCP-LISTEN:5555,bind=192.168.100.52 -
// above succeeds

Terminal B
ifconfig br0:1 down
socat TCP-CONNECT:192.168.100.52:5555 -
// connection fails

ifconfig br0:1 192.168.100.52
socat TCP-CONNECT:192.168.100.52:5555 -
// connection succeeds!!


The last connection reveals an interesting fact. It is possible for a linux process (the second socat in Terminal A) to hold an open listen socket on an interface that is not yet enabled. If we could somehow get into this state on bootup, then it would solve our delima perfectly. Unfortunately though I'm not aware of a direct way to enter this state. Somehow we'd need the Linux API to permit the first command on Terminal A to succeed.

Edited 2012-05-14 05:01 UTC

Reply Parent Score: 2