lkml.org 
[lkml]   [2013]   [Oct]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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



\
 
 \ /
  Last update: 2013-10-29 16:41    [W:0.075 / U:2.480 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site