linux-kernel - Re: [RFC][PATCH 5/5] perfcounter: Add support for kernel hardware breakpoints

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: <1248856132.6987.3034.camel@twins>
Date:	Wed, 29 Jul 2009 10:28:52 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	prasad@...ux.vnet.ibm.com, Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Mike Galbraith <efault@....de>,
	Paul Mackerras <paulus@...ba.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>,
	Lai Jiangshan <laijs@...fujitsu.com>,
	Anton Blanchard <anton@...ba.org>,
	Li Zefan <lizf@...fujitsu.com>,
	Zhaolei <zhaolei@...fujitsu.com>,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Alan Stern <stern@...land.harvard.edu>
Subject: Re: [RFC][PATCH 5/5] perfcounter: Add support for kernel hardware
 breakpoints

On Wed, 2009-07-29 at 02:36 +0200, Frederic Weisbecker wrote:
> On Tue, Jul 28, 2009 at 09:24:37AM +0200, Peter Zijlstra wrote:
> > On Tue, 2009-07-28 at 03:03 +0200, Frederic Weisbecker wrote:
> > > > Thirdly, we can multiplex perf counters beyond their hardware maximum,
> > > > something you simply cannot do for a debug interface.
> > > 
> > > 
> > > Again, I'm stuck in what you mean by multiplexing here :-)
> > 
> > If you'd create say 16 breakpoint counters, we'd RR them over the 4
> > available hardware breakpoints (or less when others are taken by someone
> > else).
> > 
> > Since its all statistics anyway, we can simply scale the event counts up
> > by the time-share they received.
> >
> 
> Aah, ok I understand now.
> But I fear it may kill the accuracy of the breakpoints statistics.
> It's fine for a theoretical linear rate of breakpoint events.
> But what happens if we are profiling something much more unstable
> with a rain of hits in a small window of memory between large timeframes?
> If we have a breakpoint inside this window of memory and this breakpoint
> is not plugged, waiting for its turn in the RR, we loose this rain of events.

You don't have to overload the breakpoint set, but we will if you create
more than there are hardware resources available.

If the RR period is independent of the application and significantly
shorter than the sample duration, statistics will be usable.

Sure, they'll not be perfect, but we can improve our confidence interval
by running longer. At some point it really doesn't matter anymore.

Take your example, of small bursts of events, due to the first
assumption - the RR period being independent of the application - we're
bound to see those busts in a proportional number of sample windows.

If the full sample duration is in the same order of the RR period, then
yes, you'll have a fair chance of missing the burst -- don't do that
then :-)

If you know you'll be running very very short, use attr.pinned, to
request a counter that'll not be multiplexed.



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