Messages in this thread | | | From | Linus Torvalds <> | Date | Wed, 30 Nov 2011 09:44:01 -0800 | Subject | Re: 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
| |