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

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:

quoted

On Thu, Dec 14, 2017 at 12:50:13PM -0600, Christopher Lameter wrote:

quoted

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.