Linux Kernel Boot Statistics: 2.6.24 To 2.6.39

[curaga]

Saved electicity is nothing when compared to enhanced productivity.
A fully productive development workstation needs 5 to 10 minutes from power off.
It takes a few seconds (to enter the screen saver password) on a powered on PC.
Can you compare the cost savings?
Moreover, saving 15 to 30 seconds a day in boot times doesn't seem to be of any real value. You loose much more in looking for a park place in the morning!

You're contradicting yourself; clearly if you have a boot time of 15s, 5 to 10 minutes is not wasted, it's 15s.

[Uqbar]

you can save 100-200? per year if you shutdown your computer more often than your 1 peer week.

now calculate this for an company with 10 000 computers.

10 000* 100? = 1 000 000-2 000 000?

means shutdown and start speed is business critical.

not for your business? maybe you give a fuck about 200? per year per pc.. but other people care.

Saved electicity is nothing when compared to enhanced productivity.
A fully productive development workstation needs 5 to 10 minutes from power off.
It takes a few seconds (to enter the screen saver password) on a powered on PC.
Can you compare the cost savings?
Moreover, saving 15 to 30 seconds a day in boot times doesn't seem to be of any real value. You loose much more in looking for a park place in the morning!

[curaga]

Yep, echoing Q and others. Even if we had perfect suspend, why the heck use 1-10W when it can be completely off at 0W?

[yoshi314]

Uhh no, previous tests were of Ubuntu releases. This testing today only the kernel is being swapped out.

i still wonder how did you manage to work around the kernel-udev incompatibility issues at certain points - some udev versions require certain range of kernel version.

[Jimmy]

What I'd like to see measured in this otherwise wonderful site is something related to MY every day use.

FIFY.

I boot once a day, because I turn my computer off at night. Yeah I know there's the half baked and very often broken suspend/hibernate support. I've spent enough time trying to get it to work right only to see it broken time and time again as something is upgraded in kernel or user land. I eventually gave up and stopped fucking with it. Even on a brand new system, I never bothered with it. Too much of a time sink for most hardware not named Thinkpad.

Also, hibernating isn't that much faster than normal booting after optimizing boot up a bit. Sure you might not be able to preserve your application state perfectly, but if you look around you can generally find good browsers, editors, and other applications which will save tabs/sessions/drafts/etc quite well.

If I can't have suspend/hibernate then I'll gladly take boot speed.

[Xake]

my kernel starts in 2 seconds, and then initrd takes over, and then init takes over. the title is very misleading and the tests are useless.

Yeah, this test has a very misleading title, as what he tests are not how fast the kernel boots, but how the Ubuntu kernel upgrades and configurations influences the boot time (as my guess is the configuration has more influence then the kernel itself ever could have).

And still there are some things he did not really do well, like not disabling readahead and other stuff that also radically can influence the boot time...

[Uqbar]

I don't think you've quite gotten the point here. All of those userland programs you refer to are directly dependent on kernel functionality.

Then someone here has to state clearly that the different kernels have been compiled with exactly the same options. Which is almost impossible as the tested kernels range from january 2008 to April 2011.

Anyway, as I stated in an earlier post, the boot timing is rather uninteresting (at least to me, though), as normally (re)boots happen very rarely.

[dargllun]

But even so I see another unclear situation, as a number of hardware devices are "hot plug" and are handled by userland programs which in turn run after the init proces has started running.

I don't think you've quite gotten the point here. All of those userland programs you refer to are directly dependent on kernel functionality. Leaving the userland program stable and just exchanging the kernel allows to clearly determine who's to blame (in a constructive manner, of course). Naturally someone now needs to follow up on this and make a closer analysis. And of course, at least theoretically, newer kernels might expose more speedy IO APIs which the 8.04 userland doesn't take advantage of. But I kind of doubt that.

I find this a very systematic test which pinpoints the overall performance development in the kernel. And it doesn't look good. Even though it's not *that* bad for x64, this may mean thoroughly bad news for a lot of x86 embedded hardware. The performance degradation might very well be portable, and thus have a much wider impact (talk about Android). Of course, maybe it's just one single sloppiness in the x86 DMA and nobody else would notice. Anyway, a closer look is a necessity.

[Uqbar]

Uhh no, previous tests were of Ubuntu releases. This testing today only the kernel is being swapped out.

Hmm ... with modern kernels even the definition of "boot time" is rather unclear.
If you mean "the time needed to spawn the init process", then the very same kernel can show different behaviors (and timing) depending upon kernel compilation decisions.
Something making more sense, again in my opinion, would then be "the time needed to initialize all hardware and to get ready to spawn the init process".
But even so I see another unclear situation, as a number of hardware devices are "hot plug" and are handled by userland programs which in turn run after the init proces has started running.

[Michael]

so, it's a benchmark where you not only test different kernels, but also different releases.

which means that the userspace is also changed, somewhere along the way, if i understand correctly.

Uhh no, previous tests were of Ubuntu releases. This testing today only the kernel is being swapped out.