To put some perspective on this I timed boot of Intrepid (Kubuntu) and
Vista on the same HP Pavilion dv7 (Turion64x2 + 4GB +sata 320G).
Times are stopwatch, YMMV.
<CR> to grub to login prompt (kdm/windows login):
Kubuntu 2.6.27-10: 44.4 sec
Vista 46.3 sec
<CR> after entering password to usable desktop:
Kubuntu 24 sec
Vista 18 sec
Both desktops continued to do things like update rss feed stuff and
restore desktop (open firefox) so the login number is a bit mushy;
basically, when the busy cursor stopped going around (much).
Both had longer boot times when either fsck had to run or Vista needed
to finish update installs. Add 1-2 mins...
Two things come to mind.
1. There is a reason why shutdown/restart is on a secondary menu w/
suspend being the button for Vista.
2. I don't have to be faster than the bear, only faster than you.
We should wring out the wasted time (lots of it) but keep perspective,
i.e. initramfs is a good thing and modules make config life easier/better.
*And* getting suspend/resume to work every time is the real win.
On Tuesday 06 January 2009 08:14:39 Scott James Remnant wrote:
> It's also worth comparing the Intrepid and Jaunty kernels in general.
> This has some key figures because we're switching to more modules
> built-in than before.
> To try and split the difference, I built two "jaunty" kernels: 2.6.28-3
> is from GIT just before the configs were changed; 2.6.28-4 is current
> GIT HEAD.
> This isn't 100% fair, since other changes have happened between the
> kernels, but it's close as feel like getting
> Bear in mind that 2.6.28-4 also includes the change to reduce the legacy
> pty count to zero, so that will affect various numbers.
> Average processing times between kernel uevent and udev completion:
> 2.6.27-9 2.6.28-3 2.6.28-4
> MEAN 6.88s 7.81s 5.01s
> MEDIAN 8.07s 8.87s 5.55s
> MODE 8.13s 2.80s 5.28s
> STDDEV 2.44s 2.67s 2.95s
> Interesting that 2.6.28 seems to take rather longer, with a much reduced
> mode (most common figure), and that 2.6.28-4 undoes that to make it
> generally faster again.
> Numbers are comparable to the legacy pty change, which isn't totally
> surprising really - the behemoth of module pain (ALSA) is still a
> General instrumenting:
> 2.6.27-9 2.6.28-3 change 2.6.28-4 change total change
> udev in initramfs: 0.01s 0.02s +0.01s (200%) 0.01s -0.01s (50%) 0
> (100%) udev in system: 0.05s 0.04s -0.01s (80%) 0.04s 0
> (100%) -0.01s (80%)
> trigger in initramfs: 0.29s 0.22s -0.07s (75%) 0.09s -0.13s
> (40%) -0.20s (31%) trigger in system: 0.60s 0.24s -0.36s (40%)
> 0.16s -0.08s (66%) -0.44s (26%)
> processing in initramfs: 2.58s 3.82s +1.24s (148%) 2.25s -1.57s
> (58%) -0.33s (87%) processing in system: 10.45s 11.86s +1.41s (113%)
> 9.37s -2.49s (79%) -1.08s (89%)
> time in kernel: 2.61s 2.61s 0 (100%) 2.63s +0.02s (100%)
> (100%) time in initramfs: 3.59s 4.56s +0.97s (127%) 2.96s -1.60s
> (64%) -0.63s (82%) (of which udev) 71% 83% 76%
> time booting system: 25.65s 26.45s +0.80s (103%) 21.54s -4.91s
> (81%) -4.11s (83%) (of which udev) 40% 44% 43%
> Again we see that 2.6.28 takes longer than 2.6.27, not just in the
> system (which we could blame on readahead) but in initramfs as well.
> More to do, maybe?
> We then see that more things as built-ins certainly reduces lots of
> overhead. The udevadm settle in initramfs drops by a third of a second,
> and the one in the main system by over a seccond.
> In total, the system comes up almost five seconds quicker.
> What's really interesting here is that the time in kernel doesn't seem
> to change at all - even with the built-ins, the initramfs starts at
> basically the same clock time.
Ubuntu Kernel Team
kernel-team mailing list