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: <alpine.DEB.2.00.1112010853430.31445@cl320.eecs.utk.edu>
Date:	Thu, 1 Dec 2011 08:59:37 -0500
From:	Vince Weaver <vweaver1@...s.utk.edu>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
CC:	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	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, 30 Nov 2011, Linus Torvalds wrote:

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

In this case, the bisection case is pretty clean.  I run 1000 of the tests 
and check the median value, and the values are always 7280us for good and 
7440us for bad.

The problem is when it starts bisecting into the merges it drops from a 
post-3.0 kernel into a much earlier 3.0-rc kernel (due to the ARM merge 
history) and suddenly then the test becomes meaningless as it starts 
returning other values such as 6880us.  This is because the problem I am 
tracking has ben gradually getting worse over time, and so I guess by 
going back to a 3.0-rc it gets earlier than some other change that made 
performance worse, and thus it becomes impossible to know if a commit is 
good or not.

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

I'll try but I'm guessing your first thought that this might be 
un-bisectabe is probably true.  

Thanks,

Vince

--
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/