From: Peter Zijlstra <peterz@infradead.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Jamie Iles <jamie@jamieiles.com>,
Paul Mackerras <paulus@samba.org>,
linux-kernel@vger.kernel.org
Subject: Re: Perf events/ARM
Date: Tue, 01 Dec 2009 15:40:44 +0100 [thread overview]
Message-ID: <1259678444.1697.487.camel@laptop> (raw)
In-Reply-To: <20091201143105.GB1183@elte.hu>
On Tue, 2009-12-01 at 15:31 +0100, Ingo Molnar wrote:
> * Jamie Iles <jamie@jamieiles.com> wrote:
>
> > Hi,
> >
> > I'm looking at adding support for the hardware performance counters in ARMv6
> > using the new perf events framework. I have a simple setup that uses the
> > counters on their own, but wrt the perf events framework:
> >
> > - what are the requirements of set_perf_event_pending() and
> > perf_event_do_pending()? As far as I can tell from sparc/x86/powerpc,
> > set_perf_event_pending() triggers an interrupt that then calls
> > perf_event_do_pending(). Does perf_event_do_pending need to run in
> > interrupt context or could I use a soft IRQ if platforms don't have a
> > spare IRQ?
>
> softirq would be fine too i suspect - but then you need to increase the
> buffering of perf_pending_head, as multiple hardirqs could hit before
> the softirq processing has finished.
>
> As that gets complex quick, an acceptable first-order approach would be
> to just ignore those lost events and run it from a softirq - i _think_
> everything should be OK.
Things like wakeups and ->event_limit might get delayed.
Delayed wakeups can be mitigated by larger buffers, delayed disable on
->event_limit is not something you can fix up.
Does your PMU generate regular interrupts or actual NMIs? If its normal
interrupts you can simply call perf_event_do_pending() at the
pmu-interrupt tail.
x86 does a self-ipi to get from NMI context into IRQ context as fast as
possible, simply because you cannot do very much from NMI context.
> > - ARM does not have proper support for atomic64's. Other than
> > performance, would there be any known problems with using the generic
> > spinlocked atomic64's?
>
> Not a problem at all. Even performance-wise they are pretty nice - Paul
> has done a nice job hashing it along 16 spinlocks - so for small SMP
> systems there should be no global cacheline bounce.
Depends, again if your PMU generates NMIs a spinlock'ed version won't
work.
next prev parent reply other threads:[~2009-12-01 14:40 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-12-01 12:04 Perf events/ARM Jamie Iles
2009-12-01 14:31 ` Ingo Molnar
2009-12-01 14:40 ` Peter Zijlstra [this message]
2009-12-01 14:53 ` Jamie Iles
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=1259678444.1697.487.camel@laptop \
--to=peterz@infradead.org \
--cc=jamie@jamieiles.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulus@samba.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.