Re: [BENCHMARK] 2.4.20-rc2-aa1 with contest

[Con Kolivas <conman@kolivas.net>]

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


>On Sat, Nov 23, 2002 at 09:29:22AM +1100, Con Kolivas wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> process_load:
>> Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
>> 2.4.18 [3]              109.5   57      119     44      1.50
>> 2.4.19 [3]              106.5   59      112     43      1.45
>> 2.4.20-rc1 [3]          110.7   58      119     43      1.51
>> 2.4.20-rc1aa1 [3]       110.5   58      117     43      1.51*
>> 2420rc2aa1 [1]          212.5   31      412     69      2.90*
>>
>> This load just copies data between 4 processes repeatedly. Seems to take
>> longer.
>
>you go into linux/include/blkdev.h and increase MAX_QUEUE_SECTORS to (2
><< (20 - 9)) and see if it makes any differences here? if it doesn't
>make differences it could be the a bit increased readhaead but I doubt
>it's the latter.

No significant difference:
2420rc2aa1              212.53  31%     412     69%
2420rc2aa1mqs2          227.72  29%     455     71%

>> xtar_load:
>> Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
>> 2.4.18 [3]              150.8   49      2       8       2.06
>> 2.4.19 [1]              132.4   55      2       9       1.81
>> 2.4.20-rc1 [3]          180.7   40      3       8       2.47
>> 2.4.20-rc1aa1 [3]       166.6   44      2       7       2.28*
>> 2420rc2aa1 [1]          217.7   34      4       9       2.97*
>>
>> Takes longer. Is only one run though so may not be an accurate average.
>
>This most probably is a too small waitqueue. Of course increasing the
>waitqueue will increase a bit the latency too for the other workloads,
>it's a tradeoff and there's no way around it. Even read-latency has the
>tradeoff when it chooses the "nth" place to be the seventh slot, where
>to put the read request if it fails inserction.
>
>> io_load:
>> Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
>> 2.4.18 [3]              474.1   15      36      10      6.48
>> 2.4.19 [3]              492.6   14      38      10      6.73
>> 2.4.20-rc1 [2]          1142.2  6       90      10      15.60
>> 2.4.20-rc1aa1 [1]       1132.5  6       90      10      15.47
>> 2420rc2aa1 [1]          164.3   44      10      9       2.24
>>
>> This was where the effect of the disk latency hack was expected to have an
>> effect. It sure did.
>
>yes, I certainly can feel the machine much more responsive during the
>write load too. Too bad some benchmark like dbench decreased
>significantly but I don't see too many ways around it. At least now with
>those changes the contigous write case is unaffected, my storage  test
>box still reads and writes at over 100mbyte/sec for example, this
>clearly means what matters is that we have 512k dma commands, not an
>huge size of the queue. Really with a loaded machine and potential
>scheduling delays it could matter more to have a larger queue, that
>maybe why the performance is decreased for some workload here too, not
>only because of a less effective elevator. So probably 2Mbyte of queue
>is a much better idea, so at least we can have a ring with 4 elements to
> refill after a completion wakeup, I wanted to be strict to see the
> "lowlatency" effect at most in the first place. We could also consider to
> use a /4 instead of my current /2 for the batch_sectors initialization.
>
>BTW, at first glance it looks 2.5 has the same problem in the queue
>sizing too.
>
>> read_load:
>> Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
>> 2.4.18 [3]              102.3   70      6       3       1.40
>> 2.4.19 [2]              134.1   54      14      5       1.83
>> 2.4.20-rc1 [3]          173.2   43      20      5       2.37
>> 2.4.20-rc1aa1 [3]       150.6   51      16      5       2.06
>> 2420rc2aa1 [1]          140.5   51      13      4       1.92
>>
>> list_load:
>> Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
>> 2.4.18 [3]              90.2    76      1       17      1.23
>> 2.4.19 [1]              89.8    77      1       20      1.23
>> 2.4.20-rc1 [3]          88.8    77      0       12      1.21
>> 2.4.20-rc1aa1 [1]       88.1    78      1       16      1.20
>> 2420rc2aa1 [1]          99.7    69      1       19      1.36
>>
>> mem_load:
>> Kernel [runs]           Time    CPU%    Loads   LCPU%   Ratio
>> 2.4.18 [3]              103.3   70      32      3       1.41
>> 2.4.19 [3]              100.0   72      33      3       1.37
>> 2.4.20-rc1 [3]          105.9   69      32      2       1.45
>>
>> Mem load hung the machine. I could not get rc2aa1 through this part of the
>> benchmark no matter how many times I tried to run it. No idea what was
>> going on. Easy to reproduce. Simply run the mem_load out of contest (which
>> runs until it is killed) and the machine will hang.
>
>sorry but what is mem_load supposed to do other than to loop forever? It
>is running for two days on my test box (512m of ram, 2G of swap, 4-way
>smp) and nothing happened yet. It's an infinite loop. Sounds like you're
>trapping a signal. Wouldn't it be simpler to just finish after a number
>of passes? The machine is perfectly usable and responsive during the
>mem_load, xmms doesn't skip a beat for istance, this is probably thanks
>to the elevator-lowlatency too, I recall xmms wasn't used to be
>completely smooth during heavy swapping in previous kernels (because the
> read() of the sound file didn't return in rasonable time since I'm swapping
> in the same hd where I store the data).
>
>jupiter:~ # uptime
>  4:20pm  up 1 day, 14:43,  3 users,  load average: 1.38, 1.28, 1.21
>jupiter:~ # vmstat 1
>   procs                      memory    swap          io     system        
> cpu r  b  w   swpd   free   buff  cache  si  so    bi    bo   in    cs  us 
> sy  id 0  1  0 197408   4504    112   1436  21  34    23    34   36    19  
> 0   2  97 0  1  0 199984   4768    116   1116 11712 5796 11720  5804  514  
> 851   1   2  97 0  1  0 234684   4280    108   1116 14344 12356 14344 12360
>  617  1034   0   3  96 0  1  0 267880   4312    108   1116 10464 11916
> 10464 11916  539   790   0   3  97 1  0  0 268704   5192    108   1116 6220
> 9336  6220  9336  363   474   0   1  99 0  1  0 270764   5312    108   1116
> 13036 18952 13036 18952  584   958   0   1  99 0  1  0 271368   5088    108
>   1116 8288 5160  8288  5160  386   576   0   1  99 0  1  1 269184   4296  
>  108   1116 4352 6420  4352  6416  254   314   0   0 100 0  1  0 266528  
> 4604    108   1116 9644 4652  9644  4656  428   658   0   1  99
>
>there is no way I can reproduce any stability problem with mem_load here
>(tested both on scsi quad xeon and ide dualathlon). Can you provide more
>details of your problem and/or a SYSRQ+T during the hang? thanks.

The machine stops responding but sysrq works. It wont write anything to the 
logs. To get the error I have to run the mem_load portion of contest, not 
just mem_load by itself. The purpose of mem_load is to be just that - a 
memory load during the contest benchmark and contest will kill it when it 
finishes testing in that load. To reproduce it yourself, run mem_load then do 
a kernel compile make -j(4xnum_cpus).  If that doesnt do it I'm not sure how 
else you can see it. sys-rq-T shows too much stuff on screen for me to make 
any sense of it and scrolls away without me being able to scroll up.

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

iD8DBQE94cbRF6dfvkL3i1gRAvkgAKCOJwQ4hP2E5n1tu1r31MeCz9tULQCdE/lm
hEbMrTEK/u2Sb8INZbVJWpg=
=8YxG
-----END PGP SIGNATURE-----