lkml.org 
[lkml]   [2008]   [Nov]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [regression] benchmark throughput loss from a622cf6..f7160c7 pull
From
Date
On Mon, 2008-11-10 at 13:50 +0100, Ingo Molnar wrote:
> * Mike Galbraith <efault@gmx.de> wrote:
>
> > Greetings,
> >
> > While retesting that recent scheduler fixes/improvements had
> > survived integration into mainline, I found that we've regressed a
> > bit since.. yesterday. In testing, it seems that CFS has finally
> > passed what the old O(1) scheduler could deliver in scalability and
> > throughput, but we already lost a bit.
>
> but CFS backported to a kernel with no other regressions measurably
> surpasses O(1) performance in all the metrics you are following,
> right?

Yes.

> i.e. the current state of things, when comparing these workloads to
> 2.6.22 is that we slowed down in non-scheduler codepaths and the CFS
> speedups helps offset some of that slowdown.

That's the way it looks to me, yes.

> But not all of it, and we also have new slowdowns:
>
> > Reverting 984f2f3 cd83e42 2d3854a and 6209344 recovered the loss.
>
> hm, that's two changes in essence:
>
> 2d3854a: cpumask: introduce new API, without changing anything
> 6209344: net: unix: fix inflight counting bug in garbage collector
>
> i'm surprised about the cpumask impact, it's just new APIs in essence,
> with little material changes elsewhere.

Dunno, I try not to look while testing, just test/report, look later.

-Mike



\
 
 \ /
  Last update: 2008-11-10 14:25    [W:0.108 / U:1.612 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site