linux-kernel - Re: perf: PERF_EVENT_IOC_PERIOD on ARM vs everywhere else

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:	Tue, 29 Oct 2013 11:36:52 -0400 (EDT)
From:	Vince Weaver <vincent.weaver@...ne.edu>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Will Deacon <will.deacon@....com>,
	Vince Weaver <vincent.weaver@...ne.edu>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...hat.com>,
	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
Subject: Re: perf: PERF_EVENT_IOC_PERIOD on ARM vs everywhere else

On Tue, 29 Oct 2013, Peter Zijlstra wrote:
> On Tue, Oct 29, 2013 at 04:28:10AM +0000, Will Deacon wrote:
> > 
> > I can CC LKML on ARM perf patches if you think it will help, but all PMU
> > backend patches go via their respective arch trees afaict.
> 
> Just those that change user visible semantics that are shared between
> archs I suppose :-)

I suppose it is hard to know what's commonly shared.  I hadn't realized
that the IOC_PERIOD stuff was arch specific code, I would have thought
it was common code.

Since there isn't a perf-specific list CCing LKML might be the answer even 
though it sometimes adds to the noise.  I think the Power people CC all 
their PMU related patches to LKML and it has made them easier to find and 
review.

> We could start by making all archs do the same thing again; but yes
> ideally we'd move some of it into generic code. Not entirely sure how
> that will work out though, there's a reason its in per-arch code :/
> 
> 
> Vince, what would you prefer to do here?

as with most of thes things there isn't really a good answer.

It turns out in the end that PAPI isn't bit by this one, because instead 
of using PERF_EVENT_IOC_PERIOD when the period is changed, PAPI just tears 
down all the perf_events and re-sets them up from scratch with the new 
period.  This is probably because PERF_EVENT_IOC_PERIOD was broken until 
2.6.36.

It is true the current behavior is unexpected.  What was the logic behind 
deferring to the next overflow for the update?  Was it a code simplicity 
thing?  Or were there hardware reasons behind it?

Definitely when an event is stopped, it makes more sense for 
PERF_EVENT_IOC_PERIOD to take place immediately.  

I'm not sure what happens if we try to use it on a running event, 
especially if we've already passed the new period value.

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/