From: Will Deacon <will.deacon@arm.com>
To: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: paulus <paulus@samba.org>,
stephane eranian <eranian@googlemail.com>,
Robert Richter <robert.richter@amd.com>,
Paul Mundt <lethal@linux-sh.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Cyrill Gorcunov <gorcunov@gmail.com>,
Lin Ming <ming.m.lin@intel.com>,
Yanmin <yanmin_zhang@linux.intel.com>,
Deng-Cheng Zhu <dengcheng.zhu@gmail.com>,
David Miller <davem@davemloft.net>, Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH 00/13] perf pmu interface changes -v3
Date: Fri, 09 Jul 2010 16:11:42 +0100 [thread overview]
Message-ID: <1278688302.9864.9.camel@e102144-lin.cambridge.arm.com> (raw)
In-Reply-To: <20100709082117.631541128@chello.nl>
Hi Peter,
On Fri, 2010-07-09 at 09:21 +0100, Peter Zijlstra wrote:
> The patches are boot tested on x86_64 and compile tested on: powerpc,
> ppc-fsl,
> sparc and arm and SH (by courtesy of Matt Fleming).
>
> X86 -- appears to be fully functional.
> FSL -- should, after the initial few fixes, at least compile again.
> ARM -- is known to have grown some issues, Will was looking into that.
I've been looking at this and after fixing atomic64 operations and a
sign-extension bug, I'm getting closer to finding the *real* cause of
the problem! It appears that the PMU isn't being enabled for pinned
events. The following patch fixes that, but I'm not sure that it's the
correct thing to do:
diff --git a/arch/arm/kernel/perf_event.c b/arch/arm/kernel/perf_event.c
index c440ae1..a946a77 100644
--- a/arch/arm/kernel/perf_event.c
+++ b/arch/arm/kernel/perf_event.c
@@ -304,6 +304,8 @@ armpmu_add(struct perf_event *event, int flags)
int idx;
int err = 0;
+ perf_pmu_disable(event->pmu);
+
/* If we don't have a space for the counter then finish early.
*/
idx = armpmu->get_event_idx(cpuc, hwc);
if (idx < 0) {
@@ -328,6 +330,7 @@ armpmu_add(struct perf_event *event, int flags)
perf_event_update_userpage(event);
out:
+ perf_pmu_enable(event->pmu);
return err;
}
Because only pinned events seem to be broken, I'm worried that this is
just hiding the problem... or is pmu->add(...) supposed to enable the
PMU as well as installing the event?
The function names aren't especially helpful here either:
armpmu_{start,stop} call armpmu->{enable,disable} and
armpmu_{enable,disable} call armpmu->{start,stop}!
Any thoughts?
Will
next prev parent reply other threads:[~2010-07-09 15:12 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-09 8:21 Peter Zijlstra
2010-07-09 8:21 ` [PATCH 01/13] perf, x86: Fix Nehalem PMU quirk Peter Zijlstra
2010-07-09 8:21 ` [PATCH 02/13] sparc64: Fix maybe_change_configuration() PCR setting Peter Zijlstra
2010-07-09 8:21 ` [PATCH 03/13] perf: Fix CPU hotplug Peter Zijlstra
2010-07-09 8:21 ` [PATCH 04/13] perf, powerpc: Use perf_sample_data_init() for the FSL code Peter Zijlstra
2010-07-09 8:21 ` [PATCH 05/13] perf, powerpc: Convert the FSL driver to use local64_t Peter Zijlstra
2010-07-09 8:21 ` [RFC][PATCH 06/13] perf: deconstify struct pmu Peter Zijlstra
2010-07-09 8:21 ` [RFC][PATCH 07/13] perf: register pmu implementations Peter Zijlstra
2010-07-09 8:21 ` [RFC][PATCH 08/13] perf: Unindent labels Peter Zijlstra
2010-07-09 8:21 ` [RFC][PATCH 09/13] perf: Reduce perf_disable() usage Peter Zijlstra
2010-07-09 8:21 ` [RFC][PATCH 10/13] perf: Per PMU disable Peter Zijlstra
2010-07-09 10:17 ` Paul Mackerras
2010-07-09 10:30 ` Peter Zijlstra
2010-07-09 10:39 ` Peter Zijlstra
2010-07-09 8:21 ` [RFC][PATCH 11/13] perf: Default PMU ops Peter Zijlstra
2010-07-09 8:21 ` [RFC][PATCH 12/13] perf: Shrink hw_perf_event Peter Zijlstra
2010-07-09 8:21 ` [RFC][PATCH 13/13] perf: Rework the PMU methods Peter Zijlstra
2010-07-10 13:36 ` Frederic Weisbecker
2010-07-10 13:47 ` Peter Zijlstra
2010-07-09 10:39 ` [RFC][PATCH 00/13] perf pmu interface changes -v3 Peter Zijlstra
2010-07-09 15:11 ` Will Deacon [this message]
2010-07-09 15:52 ` Peter Zijlstra
2010-07-09 23:34 ` Matt Fleming
2010-07-09 16:09 ` Peter Zijlstra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1278688302.9864.9.camel@e102144-lin.cambridge.arm.com \
--to=will.deacon@arm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=davem@davemloft.net \
--cc=dengcheng.zhu@gmail.com \
--cc=eranian@googlemail.com \
--cc=fweisbec@gmail.com \
--cc=gorcunov@gmail.com \
--cc=lethal@linux-sh.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.m.lin@intel.com \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
--cc=robert.richter@amd.com \
--cc=yanmin_zhang@linux.intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®