Scott James Remnant scott at
Tue Jan 6 15:59:38 GMT 2009

On the suggestion of Kay Sievers (udev upstream) we changed
CONFIG_LEGACY_PTY_COUNT from 256 to 0.  The rationale is that software
should not be using these ptys anymore, instead using UNIX98 ptys; and
that each legacy PTY costs us: 2 mknod() calls, 2 stat() calls and 4
fork()/exec() calls for each device.

So what difference does it make?

To do this, I built a kernel on Intrepid with the change - then realised
it was 2.6.27-11 from proposed that was on GIT HEAD; so the numbers
include the current Intrepid kernel (2.6.27-9), the proposed Intrepid
kernel (2.6.27-11) and the proposed Intrepid kernel with the config

First up, differences in the average time between the kernel sending a
uevent and udev finishing processing it.

	2.6.27-9	2.6.27-11	PTY_COUNT=0
MEAN	6.88s		6.95s		4.83s
MEDIAN	8.07s		8.16s		5.54s
MODE	8.13s		8.74s		8.08s
STDDEV	2.44s		2.46s		2.86s

So the mean time for event processing drops to under 5s; this is
probably because udev throttles its own queue, so events were appearing
to take longer due to the larger number of events being processed first
(the pty ones).

The median goes down too.

Now general udev timings:

			2.6.27-9	2.6.27-11	change		-11 (noptys)	change		total change
udev in initramfs:	 0.01s		 0.01s		 0     (100%)	 0.01s		 0     (100%)	 0     (100%)
udev in system:		 0.05s		 0.04s		-0.01s (80%)	 0.05s		+0.01s (125%)	 0     (100%)

trigger in initramfs:	 0.29s		 0.28s		-0.01s (96%)	 0.06s		-0.22s (21%)	-0.23s (20%)
trigger in system:	 0.60s		 0.59s		-0.01s (98%)	 0.09s		-0.50s (15%)	-0.51s (15%)

processing in initramfs: 2.58s		 2.90s		+0.32s (112%)	 2.84s		-0.06s (97%)	+0.26s (110%)
processing in system:	10.45s		10.60s		+0.15s (101%)	 9.37s		-1.23s (88%)	-1.08s (89%)

time in kernel:		 2.61s		 2.58s		-0.03s (98%)	 2.48s		-0.10s (96%)	-0.13s (95%)
time in initramfs:	 3.59s		 3.74s		+0.15s (104%)	 3.73s		-0.01s (99%)	+0.14s (103%)
(of which udev)		   71%		   77%				   76%
time booting system:	25.65s		25.86s		+0.21s (100%)	24.04s		-1.82s (92%)	-1.61s (93%)
(of which udev)		   40%		   40%				   38%

First we notice that everything takes a little longer under 2.6.27-11
than under 2.6.27-9; this is probably just the fact that readahead isn't

So it's the second set of "change" numbers we're interested in.

Notably trigger takes less time, this shouldn't be surprising, there's
something like 512 less nodes in sysfs for it to walk now.

The reduced overhead really shows up in processing as well, with over a
second less time spent in udevadm settle.

Added together, it comes to roughly 1.6s less time in boot.

Scott James Remnant
scott at

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : 

More information about the kernel-team mailing list