dbench 15% regression with 2.6.28-rc1 - Kernel

This is a discussion on dbench 15% regression with 2.6.28-rc1 - Kernel ; Comparing with 2.6.27, dbench result has regression with 2.6.28-rc1 on 2 machines. 1) 8-core stoakley: 15% 2) 8 core+mutl-thread new-model x86-64: 12% Bisect located below patch. 695698500912c4479ddf4723e492de3970ff8530 is first bad commit commit 695698500912c4479ddf4723e492de3970ff8530 Author: Peter Zijlstra Date: Tue Sep 23 ...

+ Reply to Thread
Results 1 to 3 of 3

Thread: dbench 15% regression with 2.6.28-rc1

  1. dbench 15% regression with 2.6.28-rc1

    Comparing with 2.6.27, dbench result has regression with 2.6.28-rc1 on 2 machines.
    1) 8-core stoakley: 15%
    2) 8 core+mutl-thread new-model x86-64: 12%

    Bisect located below patch.

    695698500912c4479ddf4723e492de3970ff8530 is first bad commit
    commit 695698500912c4479ddf4723e492de3970ff8530
    Author: Peter Zijlstra
    Date: Tue Sep 23 14:54:23 2008 +0200

    sched: rework wakeup preemption

    Rework the wakeup preemption to work on real runtime instead of
    the virtual runtime. This greatly simplifies the code.

    Signed-off-by: Peter Zijlstra
    Signed-off-by: Ingo Molnar


    I reverted the patch against 2.6.28-rc2 and the regression mostly disappears
    on 8-core stoakley and 8-core+multiThread x86-64 machines.


    On other 2 machines, I see improvement instead of regression.
    1) 16-core tigerton: improvement 48%
    2) 8-core+hyperThreading tulsa: 10%.
    I just checked it by reverting above patch to see if the patch improves it. At least
    it isn't on tigerton. I'm doing a new bisect on tigerton to see what patch improves
    dbench result.


    I start online cpu number of dbench processes.

    -yanmin


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

  2. Re: dbench 15% regression with 2.6.28-rc1


    On Tue, 2008-10-28 at 16:41 +0800, Zhang, Yanmin wrote:
    > Comparing with 2.6.27, dbench result has regression with 2.6.28-rc1 on 2 machines.
    > 1) 8-core stoakley: 15%
    > 2) 8 core+mutl-thread new-model x86-64: 12%
    >
    > Bisect located below patch.
    >
    > 695698500912c4479ddf4723e492de3970ff8530 is first bad commit
    > commit 695698500912c4479ddf4723e492de3970ff8530
    > Author: Peter Zijlstra
    > Date: Tue Sep 23 14:54:23 2008 +0200
    >
    > sched: rework wakeup preemption
    >
    > Rework the wakeup preemption to work on real runtime instead of
    > the virtual runtime. This greatly simplifies the code.
    >
    > Signed-off-by: Peter Zijlstra
    > Signed-off-by: Ingo Molnar
    >
    >
    > I reverted the patch against 2.6.28-rc2 and the regression mostly disappears
    > on 8-core stoakley and 8-core+multiThread x86-64 machines.
    >
    >
    > On other 2 machines, I see improvement instead of regression.
    > 1) 16-core tigerton: improvement 48%
    > 2) 8-core+hyperThreading tulsa: 10%.
    > I just checked it by reverting above patch to see if the patch improves it. At least
    > it isn't on tigerton. I'm doing a new bisect on tigerton to see what patch improves
    > dbench result.

    The improvement on tigerton isn't caused by the patch. It seems it is caused by
    other scheduler patches.

    Well, comparing with 2.6.27, the result of sysbench+mysql (oltp readonly) with 2.6.28-rc2
    has about 10% improvement, especially with high thread number. I located that's casued
    by the rework_wakeup_preemption patch.

    So the patch improves oltp result, but downgrades dbench result.

    -yanmin


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

  3. Re: dbench 15% regression with 2.6.28-rc1

    On Fri, 2008-10-31 at 17:14 +0800, Zhang, Yanmin wrote:
    > On Tue, 2008-10-28 at 16:41 +0800, Zhang, Yanmin wrote:
    > > Comparing with 2.6.27, dbench result has regression with 2.6.28-rc1 on 2 machines.
    > > 1) 8-core stoakley: 15%
    > > 2) 8 core+mutl-thread new-model x86-64: 12%
    > >
    > > Bisect located below patch.
    > >
    > > 695698500912c4479ddf4723e492de3970ff8530 is first bad commit
    > > commit 695698500912c4479ddf4723e492de3970ff8530
    > > Author: Peter Zijlstra
    > > Date: Tue Sep 23 14:54:23 2008 +0200
    > >
    > > sched: rework wakeup preemption
    > >
    > > Rework the wakeup preemption to work on real runtime instead of
    > > the virtual runtime. This greatly simplifies the code.
    > >
    > > Signed-off-by: Peter Zijlstra
    > > Signed-off-by: Ingo Molnar
    > >
    > >
    > > I reverted the patch against 2.6.28-rc2 and the regression mostly disappears
    > > on 8-core stoakley and 8-core+multiThread x86-64 machines.
    > >
    > >
    > > On other 2 machines, I see improvement instead of regression.
    > > 1) 16-core tigerton: improvement 48%
    > > 2) 8-core+hyperThreading tulsa: 10%.
    > > I just checked it by reverting above patch to see if the patch improves it. At least
    > > it isn't on tigerton. I'm doing a new bisect on tigerton to see what patch improves
    > > dbench result.

    > The improvement on tigerton isn't caused by the patch. It seems it is caused by
    > other scheduler patches.
    >
    > Well, comparing with 2.6.27, the result of sysbench+mysql (oltp readonly) with 2.6.28-rc2
    > has about 10% improvement, especially with high thread number. I located that's casued
    > by the rework_wakeup_preemption patch.
    >
    > So the patch improves oltp result, but downgrades dbench result.


    The thing is, a later patch undoes this one. I'm just not sure when its
    landed in -linus.

    This vruntime -> real-time wakeup preemption was a test to see if it
    would work because the code is so much simpler, but the sad truth is
    that it doesn't work all that well, so we went back already.

    Its just that the patch going back to vruntime based wakeup didn't make
    it in -rc1 (and possibly -rc2).



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

+ Reply to Thread