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@lists.sourceforge.net/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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
