Intrepid vs. Jaunty kernels (monolithic vs. built-in)

[Jim Lieb]

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.

Jim

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
> module.
>
>
> 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%)	
+0.02s
> (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.
>
>
> Scott

-- 
Jim Lieb
Ubuntu Kernel Team
Canonical Ltd.