2.5.46-mm1 with contest

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Here are contest results showing 2.5.46-mm1 with preempt enabled. The other kernels have it disabled.

noload:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.5.44-mm6 [3]          75.7    91      0       0       1.06
2.5.46 [2]              74.1    92      0       0       1.04
2.5.46-mm1 [5]          74.0    93      0       0       1.04

cacherun:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.5.44-mm6 [3]          69.3    99      0       0       0.97
2.5.46 [2]              67.9    99      0       0       0.95
2.5.46-mm1 [5]          68.9    99      0       0       0.96

process_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.5.44-mm6 [3]          190.6   36      166     63      2.67
2.5.45 [5]              91.0    75      33      27      1.27
2.5.46 [1]              92.9    74      36      29      1.30
2.5.46-mm1 [5]          82.7    82      21      21      1.16

Much improved

ctar_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.5.44-mm6 [3]          97.3    79      1       5       1.36
2.5.46 [1]              98.3    80      1       7       1.38
2.5.46-mm1 [5]          95.3    80      1       5       1.33

xtar_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.5.44-mm6 [3]          207.6   37      2       7       2.91
2.5.46 [1]              113.5   67      1       8       1.59
2.5.46-mm1 [5]          227.1   34      3       7       3.18

Whatever was causing this to be high in 2.5.44-mm6 is still there now.

io_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.5.44-mm6 [3]          284.1   28      20      10      3.98
2.5.46 [1]              600.5   13      48      12      8.41
2.5.46-mm1 [5]          134.3   58      6       8       1.88

Big change here. IO load is usually the one we feel the most.

read_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.5.44-mm6 [3]          104.3   73      7       4       1.46
2.5.46 [1]              103.5   75      7       4       1.45
2.5.46-mm1 [5]          103.2   74      6       4       1.45

list_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.5.44-mm6 [3]          95.3    75      1       20      1.33
2.5.46 [1]              96.8    74      2       22      1.36
2.5.46-mm1 [5]          101.4   70      1       22      1.42

mem_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.5.44-mm6 [3]          226.9   33      50      2       3.18
2.5.46 [3]              148.0   51      34      2       2.07
2.5.46-mm1 [5]          180.5   41      35      1       2.53

And this remains relatively high but better than 2.5.44-mm6

Unfortunately I've only run this with preempt enabled so far and I believe many of the improvements are showing this effect.

Con.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE9yu7eF6dfvkL3i1gRAqGIAJ9f6XFfwO0sQOVBn5qZPfAFY5JdlwCggOZt WXizAEgC23W+AURXApih9xc=
=MCT0
-----END PGP SIGNATURE-----

Nice.

Since your aim is desktop performance, I would like it if you always ran with kernel preemption enabled. That is what we are targeting for desktop performance.

Good job,

Robert Love

Mysterious.

I'd be interested in average-of-five runs both with and without preemption.

Preemption seemed to do odd things to process_load as well. gcc gained 10% and the "load" lost 40%. But the %LCPU fell only 25%, which is probably dodgy accounting. I wonder what's up with all that.

Why? We are preempting during the generic file write/read routines, I bet, which can otherwise be long periods of latency. CPU is up and I bet the throughput is down, but his test is getting the attention it wants.

Robert Love

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ok well I guess some more data is required to interpret this.

Here are the results with 2.5.46-mm1 with and without preempt (2.5.46-mmnp) only where they _differ_ for clarity:

process_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.5.44-mm6 [3]          190.6   36      166     63      2.67
2.5.46 [1]              92.9    74      36      29      1.30
2.5.46-mm1 [5]          82.7    82      21      21      1.16
2.5.46-mmnp [3]         93.8    72      37      29      1.31

Note that 2.5.46-mm1 without preempt here is comparable to 2.5.46 vanilla. Also, this one is prone to the process_load getting stuck endlessly piping data around and me having to kill the run. These were the 3 successful runs. Are the changes that fixed this problem in 2.5.44-mm6 backed out in 2.5.46-mm1? Also it seems interesting to me that preempt manages to break out of this loop and is not prone to that hang.

io_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.5.44-mm6 [3]          284.1   28      20      10      3.98
2.5.46 [1]              600.5   13      48      12      8.41
2.5.46-mm1 [5]          134.3   58      6       8       1.88
2.5.46-mmnp [4]         357.6   22      27      11      5.01

I guess this is the one we were most interested in and no doubt it takes less time with preempt enabled

A few more things to clarify that were queried: Only the kernel compilation time and cpu% are accurate. The "Loads" field takes the total number of iterations done by the load over the duration of the load running and divides it by the time the load ran over the kernel compilation time. Thus it is not reliably accurate enough because the duration the load runs beyond kernel compilation time is variable :- It takes a variable length of time to kill the load. The load cpu% (lcpu%) is that spit out by "time load" and as I said this runs for longer than the kernel compilation so will be an overestimate. I haven't found a way around this. It seems to be routine that loads done drops disproportionately when kernel compilation shortens. This seems to be more a load accounting problem (dont have a fix for that). Furthermore, since kernel compilation is -j4 and the load is one task all at the same nice level it would seem to be ideal for kernel compilation time to increase by 5/4 (and ratio to equal 1.25) , and concomitantly for cpu% to drop to 4/5 (80%) of noload.

Con.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQE9y1PeF6dfvkL3i1gRAkNXAJ47qgYAd9mygNpF7KDnzyuR6xjX3ACeORH7 Eo3HgfvJ7hJe1ykoaPEEQyQ=
=2L0b
-----END PGP SIGNATURE-----

Nah, that's the allocator changes kicking in.

-ben

"Do you seek knowledge in time travel?"