[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1234270044.23438.7.camel@twins>
Date: Tue, 10 Feb 2009 13:47:24 +0100
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Ingo Molnar <mingo@...e.hu>
Cc: Lin Ming <ming.m.lin@...el.com>, Mike Galbraith <efault@....de>,
"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
"tglx@...utronix.de" <tglx@...utronix.de>,
"oleg@...hat.com" <oleg@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"seto.hidetoshi@...fujitsu.com" <seto.hidetoshi@...fujitsu.com>
Subject: Re: [PATCH 0/2] fix the itimer regression (BZ 12618)
On Mon, 2009-02-09 at 22:47 +0100, Ingo Molnar wrote:
> * Lin Ming <ming.m.lin@...el.com> wrote:
>
> > On Fri, 2009-02-06 at 23:18 +0800, Ingo Molnar wrote:
> > > * Zhang, Yanmin <yanmin_zhang@...ux.intel.com> wrote:
> > >
> > > > On Thu, 2009-02-05 at 13:06 +0100, Ingo Molnar wrote:
> > > > > * Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
> > > > >
> > > > > > This should hopefully address all the itimer borkage.
> > > > >
> > > > > Applied to tip:timers/urgent, thanks Peter!
> > > > >
> > > > > Yanmin: could you check hacbench_pth with latest tip/master, do
> > > > > these fixes resolve that 3% regression you reported?
> > > >
> > > > Lin Ming tested it and hackbench_pth/volanoMark regression all disappear.
> > > > But oltp has a regression. We think oltp new regression isn't related to
> > > > the patch. Ming is investigating it.
> > >
> > > Potential suspects for oltp regression would be:
> > >
> > > 3d39870: sched_rt: don't use first_cpu on cpumask created with cpumask_and
> > > a571bbe: sched: fix buddie group latency
> > > a9f3e2b: sched: clear buddies more aggressively
> > > 1596e29: sched: symmetric sync vs avg_overlap
> > > d942fb6: sched: fix sync wakeups
> >
> > I tested the latest tip-master branch.
> > After reverting "d942fb6: sched: fix sync wakeups", the oltp regression
> > on the 8cores Stockley machine is mostly fixed.
> >
> > On another 4*4 cores Tigerton machine, oltp has more than 10% regression
> > with 2.6.29-rc4 compared with 2.6.29-rc3.
>
> ok, that commit needs fixed or reverted. Peter, Mike?
Yanmin, is that tigerton regression also due to the sync changes?
That is, if you revert both d942fb6 and 1596e29, does it get back to
-rc3 state, or is the tigerton regression due to something else?
This isn't quite clear to me.
Ingo, if that is the case, I'm fine with reverting those changes for
now, and have another look at them later on -- preferably when someone
ships me a 4*4 machine so I can validate :-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists