From: Peter Zijlstra <peterz@infradead.org>
To: Michael Cree <mcree@orcon.net.nz>
Cc: mingo@redhat.com, dengcheng.zhu@gmail.com,
yanmin_zhang@linux.intel.com, gorcunov@gmail.com,
fweisbec@gmail.com, robert.richter@amd.com, ming.m.lin@intel.com,
tglx@linutronix.de, hpa@zytor.com, paulus@samba.org,
linux-kernel@vger.kernel.org, eranian@googlemail.com,
will.deacon@arm.com, lethal@linux-sh.org, davem@davemloft.net,
mingo@elte.hu, linux-alpha@vger.kernel.org
Subject: Re: [tip:perf/core] perf: Rework the PMU methods
Date: Mon, 13 Sep 2010 15:18:47 +0200 [thread overview]
Message-ID: <1284383927.2275.284.camel@laptop> (raw)
In-Reply-To: <1284380153.2275.261.camel@laptop>
On Mon, 2010-09-13 at 14:15 +0200, Peter Zijlstra wrote:
> On Sun, 2010-09-12 at 17:33 +1200, Michael Cree wrote:
>
> > Yes, done. I also took the liberty to fix an undefined variable and
> > multiple defined variable errors that were exposed by compilation. Will
> > reply to this with the patch.
>
> Thanks, and sorry for messing up Alpha that bad.. I have an alpha
> compiler and I really through I compile tested it :/
>
> > I've also tested it on a UP alpha. It worked well for a little while
> > but after running 'perf top' for a number of seconds I got the following
> > warning:
>
> <snip warn>
>
> > which is from the line in alpha_pmu_start() that checks that
> > PERF_HES_STOPPED is set.
> >
> > I see that the backtrace is from the Alpha timer_interrupt() code which
> > goes something like this:
> >
> > [do some stuff updating timer deltas then...]
> >
> > #ifndef CONFIG_SMP
> > while (nticks--)
> > update_process_times(user_mode(get_irq_regs()));
> > #endif
> >
> > if (test_perf_event_pending()) {
> > clear_perf_event_pending();
> > perf_event_do_pending();
> > }
> >
> > return IRQ_HANDLED;
> > }
> >
> >
> > When I added the code for handle pending events to the timer interrupt I
> > hadn't realised that update_process_times() could call back into the
> > perf code. I'm speculating here, but could it be that there is pending
> > work to stop the HW counter, but the call to re-start it is beating the
> > call to stop it?
>
> Right, so the ->start() call came from perf_ctx_adjust_freq(), which
> depending on whether perf_adjust_period() gets inlined, can have two
> such calls.
>
> Assuming it didn't inline (there's two callsites, which should defeat
> the inline static functions with a single callsite heuristic), you hit
> the unthrottle() call.
>
> Ahh, the alpha throttle call should be using the fancy new stop function
> too (will fold into your earlier patch if it indeed works):
>
> As to the point you raised above, yes, I think it would be prudent to
> call perf_event_do_pending() before update_process_times().
>
>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Damn I suck.. Please try this one.
---
Index: linux-2.6/arch/alpha/kernel/perf_event.c
===================================================================
--- linux-2.6.orig/arch/alpha/kernel/perf_event.c
+++ linux-2.6/arch/alpha/kernel/perf_event.c
@@ -850,7 +850,7 @@ static void alpha_perf_event_irq_handler
/* Interrupts coming too quickly; "throttle" the
* counter, i.e., disable it for a little while.
*/
- cpuc->idx_mask &= ~(1UL<<idx);
+ alpha_pmu_stop(event, 0);
}
}
wrperfmon(PERFMON_CMD_ENABLE, cpuc->idx_mask);
next prev parent reply other threads:[~2010-09-13 13:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <new-submission>
[not found] ` <tip-a4eaf7f14675cb512d69f0c928055e73d0c6d252@git.kernel.org>
2010-09-11 8:16 ` [tip:perf/core] perf: Rework the PMU methods Michael Cree
2010-09-11 9:40 ` Peter Zijlstra
2010-09-12 5:33 ` Michael Cree
2010-09-12 5:37 ` [PATCH] alpha: Fix HW performance counters to be stopped properly Michael Cree
2010-09-13 12:15 ` [tip:perf/core] perf: Rework the PMU methods Peter Zijlstra
2010-09-13 13:18 ` Peter Zijlstra [this message]
2010-09-14 10:11 ` Michael Cree
2010-09-14 14:07 ` Peter Zijlstra
2010-09-15 20:25 ` Michael Cree
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=1284383927.2275.284.camel@laptop \
--to=peterz@infradead.org \
--cc=davem@davemloft.net \
--cc=dengcheng.zhu@gmail.com \
--cc=eranian@googlemail.com \
--cc=fweisbec@gmail.com \
--cc=gorcunov@gmail.com \
--cc=hpa@zytor.com \
--cc=lethal@linux-sh.org \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mcree@orcon.net.nz \
--cc=ming.m.lin@intel.com \
--cc=mingo@elte.hu \
--cc=mingo@redhat.com \
--cc=paulus@samba.org \
--cc=robert.richter@amd.com \
--cc=tglx@linutronix.de \
--cc=will.deacon@arm.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;
as well as URLs for NNTP newsgroup(s).