ubuntu-boot team mailing list archive

[Scott James Remnant <scott@xxxxxxxxxxxxx>]

This measures the difference between the udev 124 binary we're using
currently against the udev 136 binary.  I've also run a third set of
tests with Alan Jenkins' patches for a multi-threaded udev.

None of the ancillary binaries were changed, and the ruleset remained
the same, as did the kernel (2.6.27-9-generic), etc.

Compared with the previous 124 vs. 136 test, we should see much the same
results since only relatively minor changes have been made to the
binary:

https://lists.launchpad.net/ubuntu-boot/msg00004.html


Differences in memory overhead:

	udev 124	udev 136	change		udev 136 MT	change		total change
VmPeak	2523 kB		2328 kB		-195 kB (92%)	1968 kB		-360 kB (84%)	-555 kB (78%)
VmSize	2528 kB		2324 kB		-208 kB (91%)	1968 kB		-356 kB (84%)	-560 kB (77%)
VmHWM	1024 kB		 620 kB		-404 kB (60%)	 224 kB		-396 kB (36%)	-800 kB (21%)
VmRSS	1020 kB		 616 kB		-704 kB (46%)	 224 kB		-392 kB (36%)	-796 kB (21%)
VmData	 532 kB		 304 kB		-228 kB (57%)	 164 kB		 -53 kB (53%)	-368 kB (30%)

It's important to note that for the Multi-Threaded (MT) version of udev
136, there are two processes; this only measures the first - the second
actually is basically identical to unpatched udev 136.

We see much the same reduction as before from 124..136; while the MT
version is smaller, it does have a continually present second image for
the exec daemon -- however it doesn't create any new children.


Timings taken by replacing udev:

	udev 124	udev 136	udev 136 MT
MEAN	6.88s		6.61s		6.54s
MEDIAN	8.07s		7.84s		7.78s
MODE	8.13s		8.34s		8.20s
STDDEV	2.44s		2.42s		2.44s

These represent the average times between the kernel uevent being
emitted and udev completing processing of it.

Again we replicate the slightly more sprightlyness of 136 against 124,
and we see a further improvement with the Multi-Threaded version; it
processes events on average slightly quicker.


Numbers from manual instrumenting:

			udev 124	udev 136	change		udev 136 MT	change		total change
udev in initramfs:	 0.01s		 0.01s		 0     (100%)	 0.01s		 0     (100%)	 0     (100%)
udev in system:		 0.05s		 0.03s		-0.02s (60%)	 0.03s		 0     (100%)   -0.02s (60%)

trigger in initramfs:	 0.29s		 0.54s		+0.25s (186%)	 0.49s		-0.05s (90%)	+0.20s (168%)
trigger in system:	 0.60s		 0.45s		-0.15s (75%)	 0.38s		-0.07s (84%)	-0.22s (63%)

processing in initramfs: 2.58s		 2.69s		+0.11s (104%)	 2.68s		-0.01s (99%)	+0.10s (103%)
processing in system:	10.45s		 9.92s		-0.53s (94%)	 9.70s		-0.22s (97%)	-0.75s (92%)		

time in kernel:		 2.61s		 2.60s		-0.01s (99%)	 2.58s		-0.02s (99%)	-0.03s (98%)
time in initramfs:	 3.59s		 3.61s		+0.02s (100%)	 3.54s		-0.07s (98%)	-0.05s (98%)
(of which udev)		   71%		   74%				   75%
time booting system:	25.65s		24.41s		-1.24s (95%)	23.47s		-0.94s (96%)	-2.18s (91%)
(of which udev)		   40%		   40%				   41%

These are again the hardest to intrepret, with some of the figures
overlapping others.

In our previous test, we noticed an increase in time in initramfs
processing (there was an increase in trigger time as well), and we
strangely notice that again here.  This still doesn't make sense, since
udevtrigger is unmodified!

We do see the same general improvement in boot time with 136 over 124
(1.24s!, taking 0.5s less time in settle), so it's a definite win.

The MT patches look like they're a win across the board as well, taking
another second off the boot time with 0.2s less time in settle.  Over 2s
faster boot is little to be sneered at.


Scott
-- 
Scott James Remnant
scott@xxxxxxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part