2.5.44-mm6 contest results

Contest results for 2.5.44-mm6 for comparison (Shared pagetables = y):

noload:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.5.44 [6]              74.7    93      0       0       1.05
2.5.44-mm1 [3]          75.0    93      0       0       1.05
2.5.44-mm2 [3]          76.4    93      0       0       1.07
2.5.44-mm4 [3]          75.0    93      0       0       1.05
2.5.44-mm5 [7]          75.3    91      0       0       1.05
2.5.44-mm6 [3]          75.7    91      0       0       1.06

cacherun:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.5.44 [3]              68.1    99      0       0       0.95
2.5.44-mm5 [2]          68.8    99      0       0       0.96
2.5.44-mm6 [3]          69.3    99      0       0       0.97

This (cacherun) is an experimental addition to contest. It is basically how fast a second kernel compile is when conducted immediately following a previous compile.

process_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.5.44 [3]              90.9    76      32      26      1.27
2.5.44-mm1 [3]          191.5   36      168     64      2.68
2.5.44-mm2 [3]          193.5   38      161     62      2.71
2.5.44-mm4 [3]          191.1   36      166     63      2.68
2.5.44-mm5 [4]          191.4   36      166     63      2.68
2.5.44-mm6 [3]          190.6   36      166     63      2.67

ctar_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.5.44 [3]              97.7    80      1       6       1.37
2.5.44-mm1 [3]          99.2    78      1       6       1.39
2.5.44-mm2 [3]          96.9    79      1       5       1.36
2.5.44-mm4 [3]          97.1    79      1       5       1.36
2.5.44-mm5 [4]          97.7    78      1       5       1.37
2.5.44-mm6 [3]          97.3    79      1       5       1.36

xtar_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.5.44 [3]              117.0   65      1       7       1.64
2.5.44-mm1 [3]          156.2   49      2       7       2.19
2.5.44-mm2 [3]          176.1   44      2       7       2.47
2.5.44-mm4 [3]          183.3   41      2       8       2.57
2.5.44-mm5 [4]          181.1   44      2       7       2.54
2.5.44-mm6 [3]          207.6   37      2       7       2.91

io_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.5.44 [3]              873.8   9       69      12      12.24
2.5.44-mm1 [3]          347.3   22      35      15      4.86
2.5.44-mm2 [3]          294.2   28      19      10      4.12
2.5.44-mm4 [3]          358.7   23      25      10      5.02
2.5.44-mm5 [4]          270.7   29      18      11      3.79
2.5.44-mm6 [3]          284.1   28      20      10      3.98

read_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.5.44 [3]              110.8   68      6       3       1.55
2.5.44-mm1 [3]          110.5   69      7       3       1.55
2.5.44-mm2 [3]          104.5   73      7       4       1.46
2.5.44-mm4 [3]          105.6   71      6       4       1.48
2.5.44-mm5 [4]          103.3   74      6       4       1.45
2.5.44-mm6 [3]          104.3   73      7       4       1.46

list_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.5.44 [3]              99.1    71      1       21      1.39
2.5.44-mm1 [3]          96.5    74      1       22      1.35
2.5.44-mm2 [3]          94.5    75      1       22      1.32
2.5.44-mm4 [3]          96.4    74      1       21      1.35
2.5.44-mm5 [4]          95.0    75      1       20      1.33
2.5.44-mm6 [3]          95.3    75      1       20      1.33

mem_load:

Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
2.5.44 [3]              114.3   67      30      2       1.60
2.5.44-mm1 [3]          159.7   47      38      2       2.24
2.5.44-mm2 [3]          116.6   64      29      2       1.63
2.5.44-mm4 [3]          114.9   65      28      2       1.61
2.5.44-mm5 [4]          114.1   65      30      2       1.60
2.5.44-mm6 [3]          226.9   33      50      2       3.18

Mem load has dropped off again

Con

Jens, I think I prefer fifo_batch=16. We do need to expose these in /somewhere so people can fiddle with them.

Well that's one interpretation. The other is "goody, that pesky kernel compile isn't slowing down my important memory-intensive whateveritis so much". It's a tradeoff.

It appears that this change was caused by increasing the default value of /proc/sys/vm/page-cluster from 3 to 4. I am surprised.

It was only of small benefit in other tests so I'll ditch that one.

Thanks.

(You're still testing with all IO against the same disk, yes? Please rememeber that things change quite significantly when the swap IO or the io_load is against a different device)

I was hoping someone else would do comprehensive disk benchmarks with fifo_batch=32 and fifo_batch=16, but I guess that you have to currently change the define in the source doesn't make that very likely. I don't really like your global settings (for per-queue entities), but I guess they can suffice until a better approach is done.

I'll do some benching today.

Jens Axboe

Oh sure; it's just a hack so we can experiment with it. Not that anyone has, to my knowledge.

Wouldn't hurt, but it's a complex problem. Another approach would be to quietly change it and see who squeaks ;)

This test should display the speed of the memory hog, kernel compile and also how much disk i/o occurred to be really meaningful. But IMO disk i/o is the one that slows things down, so we should try to keep it as low as possible (and this test show nothing about it).

Bye.

Quoting Andrew Morton <[email protected]>:

I understand the trade off issue. Since make -j4 bzImage is 4 cpu hungry processes, ideally I'm guessing mem_load should only extend the duration and drop the cpu by 25%.

Yes I am. Sorry I just dont have the hardware to do anything else.

Con