lkml.org 
[lkml]   [2011]   [Nov]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: perf_event self-monitoring overhead regression
On Wed, Nov 30, 2011 at 3:54 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
>
> I CC'ed Linus since he's way too skilled at this git thing and always
> has good advice. There might be very good bisect advice in the lkml
> archives but I'm not sure there's anything like a HOWTO/FAQ on the
> subject other than the git-bisect manpage (ought there be one?).

Basically, "git bisect" will never really work unless you have a very
un-ambiguous case: the way bisection works (and the reason it is so
efficient) really requires that the good/bad decision be entirely
black-and-white with absolutely no room for error.

I suspect that in some performance-related thing like this, that kind
of black-and-white situation simply doesn't end up existing. For all
we know, it could be at least partly about cache layout etc, and
trying to bisect it is likely futile, unless you have a *really* good
testcase.

So bisect works really well for clear bugs that are 100% repeatable
and have a very clear "did it happen or not" signature, but I'd be
very leery indeed of using it with some performance anomaly.

That said, maybe you can get the timings to be unambiguous enough by
using 'rdtsc' in user space, and try the bisect again.

Linus


\
 
 \ /
  Last update: 2011-11-30 18:47    [W:0.099 / U:0.464 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site