lkml.org 
[lkml]   [2002]   [Nov]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [BENCHMARK] 2.4.20-rc2-aa1 with contest
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:31    [W:0.061 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site