Re: [RFC PATCH for 4.16 02/21] rseq: Introduce restartable sequences system call (v12)

[Peter Zijlstra <peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>]

On Thu, Dec 14, 2017 at 07:57:08PM +0000, Mathieu Desnoyers wrote:
> ----- On Dec 14, 2017, at 2:48 PM, Peter Zijlstra peterz-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org wrote:
> 
> > On Thu, Dec 14, 2017 at 12:50:13PM -0600, Christopher Lameter wrote:
> >> Ultimately I wish fast increments like done by this_cpu_inc() could be
> >> implemented in an efficient way on non x86 platforms that do not have
> >> cheap instructions like that.
> > 
> > So the problem isn't migration; for that we could wrap the operation in
> > preempt_disable() which is not more expensive than rseq would be. And a
> > lot more deterministic.
> > 
> > The problem instead is interrupts, which can result in nested load-store
> > operations, and that comes apart. This then means having to disable
> > interrupts over these things and _that_ is expensive.
> 
> Then could we consider checking a per task-struct rseq_cs pointer when
> returning from interrupt handler ? This rseq_cs pointer would track
> kernel restartable sequences. This would also work for NMI handlers.

I really don't much like making the interrupt handlers more expensive
for this.

And I don't think NMIs are a real worry, you should be very careful when
you share state with any of them in any case.

Also; what you can do is soft interrupt disable, which is effectively
the oppose approach, instead of restarting the sequence, you delay the
interrupt handler. And that has the obvious benefit of making all the
local_irq_disable/enable crud much faster all over.

This is something PowerPC already does.