Re: perf: PERF_EVENT_IOC_PERIOD on ARM vs everywhere else

[Vince Weaver]

On Mon, 28 Oct 2013, Will Deacon wrote:

> This was in response to complaints from both internal users and people on
> public lists:
> 
>   http://www.mail-archive.com/perfmon2-devel@xxxxxxxxxxxxxxxxxxxxx/msg02657.html
> 
> 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.

Vince
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/