linux-kernel - Re: [RFC PATCH 2/2] perf stat: Use event group to simulate PMI on PMI-less hardware counter

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]

Date:	Wed, 10 Nov 2010 15:53:04 +0100
From:	Peter Zijlstra <peterz@...radead.org>
To:	Lin Ming <ming.m.lin@...el.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Matt Fleming <matt@...sole-pimps.org>,
	"Zhang, Rui" <rui.zhang@...el.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	lkml <linux-kernel@...r.kernel.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>
Subject: Re: [RFC PATCH 2/2] perf stat: Use event group to simulate PMI on
 PMI-less hardware counter

On Wed, 2010-11-10 at 22:45 +0800, Lin Ming wrote:
> On Wed, 2010-11-10 at 20:21 +0800, Peter Zijlstra wrote:
> > On Wed, 2010-11-10 at 14:15 +0800, Lin Ming wrote:
> > > Some hardware counters(for example, Intel RAPL) can't generate interrupt
> > > when overflow. So we need to simulate the interrupt to periodically
> > > record the counter values. Otherwise, the counter may overflow and the
> > > wrong value is read.
> > > 
> > > This patch uses event group to simulate PMI as suggested by Peter
> > > Zijlstra, http://marc.info/?l=linux-kernel&m=128220854801819&w=2
> > > 
> > > create_group_counters() will create a group with 2 events, one hrtimer
> > > based event as the group leader, and the other event to count. The
> > > hrtimer is fired periodically, so the sibling event can record its
> > > counter value periodically as well.
> > 
> > I'm terribly confused here....
> > 
> >  - you introduce perf_event_attr:pmi_simulate, but then you never
> > implement it -- nor do we need it afaict.
> 
> Someone need to simluate pmi will use it in future.

Maybe, but simply adding an ABI just in case doesn't seem like a good
idea. The proposed idea was to group with a software hrtimer-based event
and use the hrtimer's sample to read the hardware group sibling using
PERF_SAMPLE_READ.

That should be possible using today's interface.

> > 
> > 
> >  - you use grouped counters for perf-stat, perf-stat doesn't use
> > sampling so I don't see a need to group events to simulate the PMI.
> > 
> 
> Aha, sorry, actually, I mean to periodically read the PMI-less counter
> and reset it to zero each time to avoid overflow.
> 
> Well, seems I have done this in the wrong way.
> Let me re-think about it.

Right, so you're wanting to avoid overflowing the hardware counter? This
is only a problem for short hardware counters without a pmi, SH and the
like currently cascade 2 32bit counters to create 64bit hardware
counters and avoid the overflow case that way.

Another thing they can do is simply use the system tick to fold the
32bit counters into a the 64bit counter.

Again, this doesn't need any changes to the ABI and generic code.



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