From patchwork Fri Jan 11 19:11:17 2013 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Sukadev Bhattiprolu X-Patchwork-Id: 211411 Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from ozlabs.org (localhost [IPv6:::1]) by ozlabs.org (Postfix) with ESMTP id 630502C03EB for ; Sat, 12 Jan 2013 06:11:48 +1100 (EST) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "e38.co.us.ibm.com", Issuer "GeoTrust SSL CA" (not verified)) by ozlabs.org (Postfix) with ESMTPS id 14B132C0349 for ; Sat, 12 Jan 2013 06:11:20 +1100 (EST) Received: from /spool/local by e38.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 11 Jan 2013 12:11:16 -0700 Received: from d03dlp03.boulder.ibm.com (9.17.202.179) by e38.co.us.ibm.com (192.168.1.138) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Fri, 11 Jan 2013 12:11:13 -0700 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by d03dlp03.boulder.ibm.com (Postfix) with ESMTP id 4426319D803F for ; Fri, 11 Jan 2013 12:11:10 -0700 (MST) Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r0BJB6ZO161536 for ; Fri, 11 Jan 2013 12:11:09 -0700 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r0BJB3lt023254 for ; Fri, 11 Jan 2013 12:11:04 -0700 Received: from suka ([9.47.24.134]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id r0BJB3bc023211; Fri, 11 Jan 2013 12:11:03 -0700 Received: by suka (Postfix, from userid 155514) id 74E3262C4; Fri, 11 Jan 2013 11:11:17 -0800 (PST) Date: Fri, 11 Jan 2013 11:11:17 -0800 From: Sukadev Bhattiprolu To: Benjamin Herrenschmidt Subject: [PATCH] perf/Power: PERF_EVENT_IOC_ENABLE does not reenable event Message-ID: <20130111191117.GA9407@us.ibm.com> MIME-Version: 1.0 Content-Disposition: inline X-Operating-System: Linux 2.0.32 on an i486 User-Agent: Mutt/1.5.20 (2009-06-14) X-Content-Scanned: Fidelis XPS MAILER x-cbid: 13011119-5518-0000-0000-00000AA99DA5 Cc: Maynard Johnson , Anton Blanchard , paulus@samba.org, linuxppc-dev@lists.ozlabs.org X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@lists.ozlabs.org Sender: "Linuxppc-dev" If we disable a perf event because we exceeded the specified ->event_limit, power_pmu_stop() sets the PERF_HES_STOPPED flag on the event. If the application then re-enables the event using PERF_EVENT_IOC_ENABLE ioctl, we don't seem to ever clear this STOPPED flag. Consequently, the user space is never notified of the event. Following message has more background and test case. http://lists.eecs.utk.edu/pipermail/ptools-perfapi/2012-October/002528.html The problem reported there does not seem to occur on x86. My unverified theory: Both x86 and Power clear the event->hw.state flag to 0 in their ->pmu_start() operations. On X86 x86_pmu_start() is called from x86_pmu_enable(). But on Power, power_pmu_start() is not called from power_pmu_enable(). Used the following test cases to verify that this patch works on latest PAPI. $ papi.git/src/ctests/nonthread PAPI_TOT_CYC@5000000 $ papi.git/src/ctests/overflow_single_event Signed-off-by: Sukadev Bhattiprolu --- arch/powerpc/perf/core-book3s.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/arch/powerpc/perf/core-book3s.c b/arch/powerpc/perf/core-book3s.c index aa2465e..a6faada 100644 --- a/arch/powerpc/perf/core-book3s.c +++ b/arch/powerpc/perf/core-book3s.c @@ -880,8 +880,16 @@ static int power_pmu_add(struct perf_event *event, int ef_flags) cpuhw->events[n0] = event->hw.config; cpuhw->flags[n0] = event->hw.event_base; + /* + * If this event was disabled in record_and_restart() because we + * exceeded the ->event_limit, this is probably a good time to + * re-enable the event ? If we don't reenable the event, we will + * never notify the user again about this event. + */ if (!(ef_flags & PERF_EF_START)) event->hw.state = PERF_HES_STOPPED | PERF_HES_UPTODATE; + else + event->hw.state &= ~PERF_HES_STOPPED; /* * If group events scheduling transaction was started,