Messages in this thread | | | Subject | Re: hackbench regression with kernel 2.6.32-rc1 | From | Peter Zijlstra <> | Date | Mon, 12 Oct 2009 16:21:04 +0200 |
| |
On Mon, 2009-10-12 at 15:05 +0800, Zhang, Yanmin wrote:
> > So hackbench is a multi-cast, with one sender spraying multiple > > receivers, who in their turn don't spray back, right?
> Right. volanoMark has about 9% regression on stoakley and 50% regression > on tigerton. If I revert the original patches, volanoMark regression on stoakley > disappears, but still has about 45% on tigerton.
> > /me ponders a bit > > > > Does this make it any better?
> I apply this patch and another one you sent on tbench email thread. > On stoakley, hackbench is recovered. If reverting the original 2 patches, > we get 8% improvement. > On tigerton, with your 2 patches, there is still about 45% regression.
[ and here I got confused because this 45% seemed to match the 45% above, but then I saw it was hackbench vs volano ]
> As for volanoMark, with your 2 patches, regression disappears on staokley > and it becomes about 35% on tigerton.
So hackbench on tigerton is worse, but volano on tigerton is better with this patch vs reverting bits?
> The good news is only tbench has about 6% regression on Nehalem machines. > Other regressions such like hackbench/aim7/volanoMark is not clear/big on > Nehalem. But reverting the original 2 patches don't fix the tbench regression > on Nehalem machines.
Right, so Mike's suggestion of doing: echo NEXT_BUDDY > /debug/sched_features
Seems like the next thing to try..
Mike, did we ever figure out _why_ NEXT_BUDDY introduced latencies?
Buddies shouldn't make latencies worse than regular while(1); loops would.
| |