Re: [PATCH 4/8] ARCv2: perf: Support sampling events using overflow interrupts

[Vineet Gupta]

On Tuesday 16 June 2015 02:37 PM, Peter Zijlstra wrote:
> On Tue, Jun 16, 2015 at 05:37:40AM +0000, Vineet Gupta wrote:
>> > On Monday 15 June 2015 09:55 PM, Peter Zijlstra wrote:
>>> > > On Tue, Jun 09, 2015 at 05:49:28PM +0530, Vineet Gupta wrote:
>>>> > >> +	if (arc_pmu->has_interrupts) {
>>>> > >> +		int irq = platform_get_irq(pdev, 0);
>>> > > Hmm, so you're requesting a regular interrupt.
>>> > >
>>> > > I see your architecture has IRQ priorities, could you play games and
>>> > > create NMIs using those?
>>> > >
>>> > > For example, never mask L1 (assuming that's the highest priority) and
>>> > > treat that as an NMI.
>> > 
>> > I've had this idea before, however, while ARCv2 provides hardware interrupt
>> > priorities, we really can't implement true NMI, because CLRI / SETI used at
>> > backend of loal_irq_save() / restore() impact all priorities (statsu32 register
>> > has a global enable interrupt bit which these wiggle). So e.g. a
>> > spin_lock_irqsave() will lock out even the perf interrupt.
> Hmm, bugger. I (of course) only looked at the kernel source, since that
> is all I have, and the current arch/arc/ frobs with those two En bits in
> status32.
> 
> So arcv2 changed all that, shame.

Turns out that it is possible to implement NMI on ARCv2 in a pretty
straightforward way.

Our RTOS Guru, Chuck, told me off list, that instead of using CLRI / SETI, we can
use SETI with different args which would keep the stat32.IE enabled all the times,
but wiggle the stat32.E[ ] to change the intr prio level, effectively locking out
only lower prio interrupts in any local_irq_save() / restore() region.
But isn't this defying the irq disable/enable semantics and could lead to
potential breach of *some* critical section.

Neverthless, doing this requires some more changes in ARCv2 support code - so for
now we will go with the normal interrupts and later bolt on the NMI emulation.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/