From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
To: Peter Zijlstra <peterz@infradead.org>
Cc: arcml <linux-snps-arc@lists.infradead.org>,
Alexey Brodkin <Alexey.Brodkin@synopsys.com>,
lkml <linux-kernel@vger.kernel.org>
Subject: NMI for ARC
Date: Tue, 17 Nov 2015 18:23:21 +0530 [thread overview]
Message-ID: <564B2341.4030409@synopsys.com> (raw)
In-Reply-To: <20151117122540.GL11639@twins.programming.kicks-ass.net>
On Tuesday 17 November 2015 05:55 PM, Peter Zijlstra wrote:
> This is assuming you now have these NMIs we talked about earlier. If all
> you have are regular IRQs this is not possible, for we should be calling
> ->read() with IRQs disabled.
>
No we don't yet. The first stab at it fell flat on floor.
The NMI support from hardware is that is it provides different priorities, higher
one obviously able to interrupt lower one. However instructions like CLRI (disable
interrupts) will still lock out all interrupts.
Thus local_irq_save()/restore() and local_irq_enable()/disable() now need to be
contextual.
- When running in prio 0 mode, they only need to enable 0
- In prio 1, they need to enable both 0 and 1
For irq_save()/restore() this is achievable by doing an additional STATUS32 read
at the time of save and passing that value to restore - so there's an additional
overhead - but ignoring that for now.
Bummer is irq_disable()/enable() case: there's need to pass old prio state from
enable to disabled, so we need some sort of global state tracking - which in case
of SMP needs to be per cpu.... either keep something hot in a reg or pay the cost
of additional mem/cache line miss.
I've not investigated how other arches do that. PPC seems to be using some sort of
soft irq state anyways.
next prev parent reply other threads:[~2015-11-17 12:53 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1445286926.3913.13.camel@synopsys.com>
2015-11-17 9:14 ` local64_cmpxchg() in arc_perf_event_update() Vineet Gupta
2015-11-17 11:07 ` Peter Zijlstra
2015-11-17 11:23 ` Vineet Gupta
2015-11-17 12:24 ` Peter Zijlstra
2015-11-17 12:25 ` Peter Zijlstra
2015-11-17 12:53 ` Vineet Gupta [this message]
2015-11-17 13:15 ` NMI for ARC Peter Zijlstra
2016-09-28 0:22 ` Vineet Gupta
2016-09-28 7:16 ` Peter Zijlstra
2016-09-28 17:58 ` Vineet Gupta
2016-09-28 19:25 ` Andy Lutomirski
2016-09-28 20:37 ` Peter Zijlstra
2016-09-28 22:26 ` Andy Lutomirski
2016-09-28 22:44 ` Vineet Gupta
2016-09-28 22:47 ` Andy Lutomirski
2016-09-29 1:20 ` Vineet Gupta
2016-09-29 6:43 ` Peter Zijlstra
2016-09-29 16:47 ` Vineet Gupta
2016-09-29 18:54 ` Andy Lutomirski
2016-09-29 19:48 ` Vineet Gupta
2016-09-30 10:49 ` Peter Zijlstra
2016-09-29 17:30 ` Andy Lutomirski
2015-11-17 13:24 ` local64_cmpxchg() in arc_perf_event_update() Vineet Gupta
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=564B2341.4030409@synopsys.com \
--to=vineet.gupta1@synopsys.com \
--cc=Alexey.Brodkin@synopsys.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-snps-arc@lists.infradead.org \
--cc=peterz@infradead.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