[lkml]   [2013]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: perf: PERF_EVENT_IOC_PERIOD on ARM vs everywhere else
On Mon, 28 Oct 2013, Will Deacon wrote:

> This was in response to complaints from both internal users and people on
> public lists:
> I believe the scenario was something like:
> (1) An instruction counter is set up to overflow after 200 instructions,
> with a SIGIO handler to print some information. It is initially
> disabled.
> (2) At some point, the counter is enabled for 1 overflow (IOC_REFRESH)
> (3) The counter eventually overflows and the SIGIO handler is triggered.
> At this pointer the counter is disabled.
> (4) The signal handler changes the period to 200k instructions using
> IOC_PERIOD and enables the counter for a further overflow.
> (5) SIGIO is taken after 200 instructions, rather than 200k.

It would be nice if changelogs for patches had this level of detail.

It's also a shame this change apprently didn't hit the linux-kernel list
as far as I can tell. I do my best to try to note all of the perf
ABI-related changes there, but if things like this are going to start
getting merged in architecture trees then things get that much harder
to keep track of.

> I don't want to be the `oddball' architecture (at least, not more than I am
> already :), but I do find it tricky to follow the required semantics of perf
> as opposed to `it happens to work this way', especially when so much of it
> is buried in the various arch backends. So if somebody using the thing on
> ARM has (what looks to me like) a valid issue, then I usually try and fix
> it.

But it was global behavior that was common on all architectures.

Now any cross-platform tool like PAPI is going to have to have a mess of
#ifdefs around every use of this ioctl, and it will only get worse if
other architectures decide to "fix" the problem too.


 \ /
  Last update: 2013-10-28 15:21    [W:0.110 / U:1.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site