[lkml]   [2009]   [Sep]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [quad core results] BFS vs. mainline scheduler benchmarks and measurements

    * Markus T?rnqvist <> wrote:

    > Please Cc me as I'm not a subscriber.
    > On Mon, Sep 07, 2009 at 02:16:13PM +0200, Ingo Molnar wrote:
    > >
    > >Con posted single-socket quad comparisons/graphs so to make it 100%
    > >apples to apples i re-tested with a single-socket (non-NUMA) quad as
    > >well, and have uploaded the new graphs/results to:
    > >
    > > kernel build performance on quad:
    > >
    > [...]
    > >
    > >It shows similar curves and behavior to the 8-core results i posted
    > >- BFS is slower than mainline in virtually every measurement. The
    > >ratios are different for different parts of the graphs - but the
    > >trend is similar.
    > Dude, not cool.
    > 1. Quad HT is not the same as a 4-core desktop, you're doing it with 8 cores

    No, it's 4 cores. HyperThreading adds two 'siblings' per core, which
    are not 'cores'.

    > 2. You just proved BFS is better on the job_count == core_count case, as BFS
    > says it is, if you look at the graph

    I pointed that out too. I think the graphs speak for themselves:

    > 3. You're comparing an old version of BFS against an unreleased dev kernel

    bfs-208 was 1 day old (and it is a 500K+ kernel patch) when i tested
    it against the 2 days old sched-devel tree. Btw., i initially
    measured 205 as well and spent one more day on acquiring and
    analyzing the 208 results.

    There's bfs-209 out there today. These tests take 8+ hours to
    complete and validate. I'll re-test BFS in the future too, and as i
    said it in the first mail i'll test it on a .31 base as well once
    BFS has been ported to it:

    > > It's on a .31-rc8 base while BFS is on a .30 base - will be able
    > > to test BFS on a .31 base as well once you release it. (but it
    > > doesnt matter much to the results - there werent any heavy core
    > > kernel changes impacting these workloads.)

    > Also, you said on
    > "I also tried to configure the kernel in a BFS friendly way, i used
    > HZ=1000 as recommended, turned off all debug options, etc. The
    > kernel config i used can be found here:
    > "
    > Quickly looking at the conf you have
    > CONFIG_HZ_250=y
    > # CONFIG_PREEMPT is not set

    Indeed. HZ does not seem to matter according to what i see in my
    measurements. Can you measure such sensitivity?

    > And other DEBUG.

    These are the defaults and they dont make a measurable difference to
    these results. What other debug options do you mean and do they make
    a difference?


     \ /
      Last update: 2009-09-07 16:03    [W:0.024 / U:4.568 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site