On 11/17/2017 03:42 PM, Vineet Gupta wrote:
What do you (on ARC) do about irq_work ?
So the reason I'm asking is that some architectures that don't have NMIs
call irq_work_run() at the very end of their perf-interrupt handler (ARM
does this for instance).
But on ARC, we don't call
But I was choosing to ignore it mainly to reduce the overhead of a
perf intr in general. A subsequent real interrupt could go thru thru
the gyrations of preemption etc.
So that's dangerous thinking... People that run a PREEMPT kernel
generally tend to care about latency (esp. when combined
On Tue, Nov 14, 2017 at 03:01:26PM -0800, Vineet Gupta wrote:
> On 11/14/2017 02:28 AM, Peter Zijlstra wrote:
> > On Tue, Nov 07, 2017 at 02:13:04PM -0800, Vineet Gupta wrote:
> > > In the more likely case of returning to kernel from perf interrupt, do a
> > > fast path returning w/o bothering
On 11/14/2017 02:28 AM, Peter Zijlstra wrote:
On Tue, Nov 07, 2017 at 02:13:04PM -0800, Vineet Gupta wrote:
In the more likely case of returning to kernel from perf interrupt, do a
fast path returning w/o bothering about CONFIG_PREEMPT etc
I think this needs more explaining and certainly also
On Tue, Nov 07, 2017 at 02:13:04PM -0800, Vineet Gupta wrote:
> In the more likely case of returning to kernel from perf interrupt, do a
> fast path returning w/o bothering about CONFIG_PREEMPT etc
I think this needs more explaining and certainly also deserves a code
comment.
Is the argument
In the more likely case of returning to kernel from perf interrupt, do a
fast path returning w/o bothering about CONFIG_PREEMPT etc
However, if returning to user space, need do go thru the usual gyrations,
as check for pending signals is an absolute must.
Signed-off-by: Vineet Gupta
