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.023 / U:1.540 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site