Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756691Ab3J1N7x (ORCPT ); Mon, 28 Oct 2013 09:59:53 -0400 Received: from mail-qc0-f175.google.com ([209.85.216.175]:45630 "EHLO mail-qc0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756441Ab3J1N7w (ORCPT ); Mon, 28 Oct 2013 09:59:52 -0400 Date: Mon, 28 Oct 2013 10:07:48 -0400 (EDT) From: Vince Weaver To: Will Deacon cc: Vince Weaver , "linux-kernel@vger.kernel.org" , Peter Zijlstra , Ingo Molnar , Arnaldo Carvalho de Melo Subject: Re: perf: PERF_EVENT_IOC_PERIOD on ARM vs everywhere else In-Reply-To: <20131028085700.GB20218@mudshark.cambridge.arm.com> Message-ID: References: <20131028085700.GB20218@mudshark.cambridge.arm.com> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2129 Lines: 50 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 majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/