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

[Andrew Morton <akpm@digeo.com>]

Con Kolivas wrote:
> 
> -----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%

process_load is a CPU scheduler thing, not a disk scheduler thing.  Something
must have changed in kernel/sched.c.

It's debatable whether 210 seconds is worse than 110 seconds in
this test, really.  You have four processes madly piping stuff around and
four to eight processes compiling stuff.  I don't see why it's "worse"
that the compile happens to get 31% of the CPU time in this kernel.  One
would need to decide how much CPU it _should_ get before making that decision.

> ...
> 
> 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.

Try sysrq-p.