lkml.org 
[lkml]   [2003]   [Jan]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [BENCHMARK] 2.5.5{4,5,6,7,8} with contest
Date
On Thursday 16 Jan 2003 10:45 pm, Andrew Morton wrote:
> Con Kolivas <conman@kolivas.net> wrote:
> > dbench_load:
> > Kernel [runs] Time CPU% Loads LCPU% Ratio
> > 2.5.54 3 118 66.1 3 24.6 1.49
> > 2.5.55 3 117 68.4 2 16.2 1.50
> > 2.5.56 3 89 60.7 4 24.7 1.13
> > 2.5.57 4 96 64.6 2 20.7 1.22
> > 2.5.58 3 122 64.8 3 24.6 1.54
>
> Is this statistically significant?

It's taking me a while to catch up with the contest code rewrite. A quick
perusal of the results shows a couple of dud runs in the .56 and .57 dbench
results, so no. Should have audited them first. Here's a corrected set with
the dud results removed:

dbench_load:
Kernel [runs] Time CPU% Loads LCPU% Ratio
2.5.54 3 118 66.1 3 24.6 1.49
2.5.55 3 117 68.4 2 16.2 1.50
2.5.56 2 124 62.9 3 25.8 1.57
2.5.57 3 121 64.5 3 22.3 1.53
2.5.58 3 122 64.8 3 24.6 1.54

No change there sorry.

>
> Looks like the I/O scheduler has slipped a bit. Nick did some testing
> which shows that read-latency2 is still outperforming 2.5 by a factor of
> twenty on read-vs-write fairness. He's working on that, but there is still
> a lot to do on this front. We are nowhere near good enough yet.
>
> > A full set of archived results and hardware specs can be found here:
> > http://www.osdl.org/projects/ctdevel/results/
> >
> > This is a good time to repeat the bug report that looked like spam last
> > time I posted it (sorry my mailer seemed to bork):
> >
> > Since moving contest to c I get an error trying to fork with all 2.5
> > kernels I try after running it on the 6th load. The error does not occur
> > with any 2.4 kernels. I have confirmed it is still present on 2.5.58.
> >
> > To reproduce the problem:
> > Run the latest version of contest without arguments (0.61pre) and after
> > no_load,cacherun,process_load,ctar_load,xtar_load and io_load it bombs
> > out with:
> > bmark.c:43: SYSTEM ERROR: Cannot allocate memory : fork error
> >
> > It seems to occur only after a few loads followed by io_load.
>
> Ho hum. "it works for me".
>
> My guess would be that ext3 has confused vm_enough_memory(). See, if you
> delete an ext3 file immediately after writing it (as io_load does), ext3
> will leave all the pages on the page LRU, with attached buffers.
>
> These pages are trivially reclaimable, but as far as the VM accounting is
> concerned these pages are nowhere to be seen. So vm_enough_memory() says
> "nope, not enough memory to fork". Perhaps.
>
> Could you please do
>
> echo 1 > /proc/sys/vm/overcommit_memory
>
> and see if it goes away?

Yes that fixes it.

Con
-
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:32    [W:0.048 / U:0.232 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site