Re: [performance regression, bisected] scheduler: should_we_balance() kills filesystem performance

2013-09-10 Thread Peter Zijlstra
On Tue, Sep 10, 2013 at 01:47:59PM +0900, Joonsoo Kim wrote: > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > index 7f0a5e6..9b3fe1c 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -5151,7 +5151,7 @@ static int should_we_balance(struct lb_env *env) > * First

Re: [performance regression, bisected] scheduler: should_we_balance() kills filesystem performance

2013-09-10 Thread Joonsoo Kim
On Tue, Sep 10, 2013 at 04:15:20PM +1000, Dave Chinner wrote: > On Tue, Sep 10, 2013 at 01:47:59PM +0900, Joonsoo Kim wrote: > > On Tue, Sep 10, 2013 at 02:02:54PM +1000, Dave Chinner wrote: > > > Hi folks, > > > > > > I just updated my performance test VM to the current 3.12-git > > > tree after

Re: [performance regression, bisected] scheduler: should_we_balance() kills filesystem performance

2013-09-10 Thread Dave Chinner
On Tue, Sep 10, 2013 at 01:47:59PM +0900, Joonsoo Kim wrote: > On Tue, Sep 10, 2013 at 02:02:54PM +1000, Dave Chinner wrote: > > Hi folks, > > > > I just updated my performance test VM to the current 3.12-git > > tree after the XFS dev branch was merged. The first test I ran > > which was a

Re: [performance regression, bisected] scheduler: should_we_balance() kills filesystem performance

2013-09-10 Thread Dave Chinner
On Tue, Sep 10, 2013 at 01:47:59PM +0900, Joonsoo Kim wrote: On Tue, Sep 10, 2013 at 02:02:54PM +1000, Dave Chinner wrote: Hi folks, I just updated my performance test VM to the current 3.12-git tree after the XFS dev branch was merged. The first test I ran which was a 16-way

Re: [performance regression, bisected] scheduler: should_we_balance() kills filesystem performance

2013-09-10 Thread Joonsoo Kim
On Tue, Sep 10, 2013 at 04:15:20PM +1000, Dave Chinner wrote: On Tue, Sep 10, 2013 at 01:47:59PM +0900, Joonsoo Kim wrote: On Tue, Sep 10, 2013 at 02:02:54PM +1000, Dave Chinner wrote: Hi folks, I just updated my performance test VM to the current 3.12-git tree after the XFS dev

Re: [performance regression, bisected] scheduler: should_we_balance() kills filesystem performance

2013-09-10 Thread Peter Zijlstra
On Tue, Sep 10, 2013 at 01:47:59PM +0900, Joonsoo Kim wrote: diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 7f0a5e6..9b3fe1c 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -5151,7 +5151,7 @@ static int should_we_balance(struct lb_env *env) * First idle

Re: [performance regression, bisected] scheduler: should_we_balance() kills filesystem performance

2013-09-09 Thread Joonsoo Kim
On Tue, Sep 10, 2013 at 02:02:54PM +1000, Dave Chinner wrote: > Hi folks, > > I just updated my performance test VM to the current 3.12-git > tree after the XFS dev branch was merged. The first test I ran > which was a 16-way concurrent fsmark test to create lots of files > gave me a number about

[performance regression, bisected] scheduler: should_we_balance() kills filesystem performance

2013-09-09 Thread Dave Chinner
Hi folks, I just updated my performance test VM to the current 3.12-git tree after the XFS dev branch was merged. The first test I ran which was a 16-way concurrent fsmark test to create lots of files gave me a number about 30% lower than I expected - ~180k files/s when I was expecting somewhere

[performance regression, bisected] scheduler: should_we_balance() kills filesystem performance

2013-09-09 Thread Dave Chinner
Hi folks, I just updated my performance test VM to the current 3.12-git tree after the XFS dev branch was merged. The first test I ran which was a 16-way concurrent fsmark test to create lots of files gave me a number about 30% lower than I expected - ~180k files/s when I was expecting somewhere

Re: [performance regression, bisected] scheduler: should_we_balance() kills filesystem performance

2013-09-09 Thread Joonsoo Kim
On Tue, Sep 10, 2013 at 02:02:54PM +1000, Dave Chinner wrote: Hi folks, I just updated my performance test VM to the current 3.12-git tree after the XFS dev branch was merged. The first test I ran which was a 16-way concurrent fsmark test to create lots of files gave me a number about 30%