linux-kernel - Re: perf_event self-monitoring overhead regression

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+55aFwyYdN7HOkP0xanUOWd12zZhdqHCjnsWtdrs5LOxjg+Gg@mail.gmail.com>
Date:	Wed, 30 Nov 2011 09:44:01 -0800
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Cc:	Vince Weaver <vweaver1@...s.utk.edu>, Ingo Molnar <mingo@...e.hu>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Paul Mackerras <paulus@...ba.org>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
	Stephane Eranian <eranian@...il.com>
Subject: Re: perf_event self-monitoring overhead regression

On Wed, Nov 30, 2011 at 3:54 AM, Peter Zijlstra <a.p.zijlstra@...llo.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
--
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/