public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Max Filippov <jcmvbkbc@gmail.com>
Cc: "linux-xtensa@linux-xtensa.org" <linux-xtensa@linux-xtensa.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Chris Zankel <chris@zankel.net>, Marc Gauthier <marc@cadence.com>,
	Paul Mackerras <paulus@samba.org>, Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>
Subject: Re: [PATCH 7/8] xtensa: implement counting and sampling perf events
Date: Mon, 6 Jul 2015 16:05:03 +0200	[thread overview]
Message-ID: <20150706140503.GJ3644@twins.programming.kicks-ass.net> (raw)
In-Reply-To: <CAMo8BfLqi+Z_Ga_3KCQbegvBOHM_SL7dJC99BV8f2SDsdj93uA@mail.gmail.com>

On Mon, Jul 06, 2015 at 04:56:09PM +0300, Max Filippov wrote:
> On Mon, Jul 6, 2015 at 4:47 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> > On Mon, Jul 06, 2015 at 04:32:48PM +0300, Max Filippov wrote:
> >> +static int __init xtensa_pmu_init(void)
> >> +{
> >> +     int ret;
> >> +     int irq = irq_create_mapping(NULL, XCHAL_PROFILING_INTERRUPT);
> >
> > Does this platform have interrupt priorities which you can partially
> > mask in order to create NMI like behaviour?
> 
> Not sure what you mean by "NMI like".

There's a number of archs where we implement NMIs by having
local_irq_disable() only disable part of the interrupt priority range
and making sure all 'normal' IRQs are mapped in that priority range.

We then map our NMI handlers to a priority above the 'normal' range,
such that these interrupts can indeed happen when interrupts are
'disabled.

See for example:

b4f4372f96e0 ("sparc64: Make %pil level 15 a pseudo-NMI.")
0c25e9e6cbe7 ("sparc64: Adjust __raw_local_irq_save() to cooperate in NMIs.")
c011f80ba091 ("sparc64: Add some more commentary to __raw_local_irq_save()")

> Interrupt priorities are fixed in the current xtensa architecture, and
> we can in theory mask certain level and below, but practically we
> always mask all low- and medium- level interrupts.
> 
> Also we currently can't have handlers for high priority interrupts written in C.

Why not? Surely this can be cured with an assembly stub?

The advantage of having NMIs is that profiling information for the
kernel becomes much more useful. Without this local_irq_enable() will be
a very 'hot' function.

  reply	other threads:[~2015-07-06 14:05 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-07-06 13:32 [PATCH 0/8] Support hardware perf counters on xtensa Max Filippov
2015-07-06 13:32 ` [PATCH 1/8] xtensa: clean up Kconfig dependencies for custom cores Max Filippov
2015-07-07  9:18   ` Paul Bolle
2015-07-06 13:32 ` [PATCH 2/8] xtensa: keep exception/interrupt stack continuous Max Filippov
2015-07-07 18:47   ` Chris Zankel
2015-07-07 19:46     ` Max Filippov
2015-07-07 19:47       ` Max Filippov
2015-07-06 13:32 ` [PATCH 3/8] xtensa: move oprofile stack tracing to stacktrace.c Max Filippov
2015-07-06 13:32 ` [PATCH 4/8] xtensa: select PERF_USE_VMALLOC for cache-aliasing configurations Max Filippov
2015-07-06 13:32 ` [PATCH 5/8] xtensa: add profiling IRQ type to xtensa_irq_map Max Filippov
2015-07-06 13:32 ` [PATCH 6/8] xtensa: count software page fault perf events Max Filippov
2015-07-06 13:32 ` [PATCH 7/8] xtensa: implement counting and sampling " Max Filippov
2015-07-06 13:41   ` Peter Zijlstra
2015-07-06 13:49     ` Max Filippov
2015-07-06 13:47   ` Peter Zijlstra
2015-07-06 13:56     ` Max Filippov
2015-07-06 14:05       ` Peter Zijlstra [this message]
2015-07-06 14:22         ` Max Filippov
2015-07-07  3:56           ` Chris Zankel
2015-07-06 13:32 ` [PATCH 8/8] perf tools: xtensa: add DWARF register names Max Filippov

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=20150706140503.GJ3644@twins.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=acme@kernel.org \
    --cc=chris@zankel.net \
    --cc=jcmvbkbc@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-xtensa@linux-xtensa.org \
    --cc=marc@cadence.com \
    --cc=mingo@redhat.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox