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

[Christopher Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>]

On Thu, 14 Dec 2017, Mathieu Desnoyers wrote:

> > I think the proper way to think about gs and fs on x86 is as base
> > registers. They are essentially values in registers added to the address
> > generated in an instruction. As such the approach is transferable to other
> > processor architecture. Many support base register and base register
> > relative processing. If a processor can do RMV instructions base register
> > relative then you have something similar.
>
> How would you do it on ARM32 ?

Actually you do not really need RMV instructions. The data is cpu specific
so within a restartable sequence you would have exclusive access right?

F.e. a increment would be

1. Load base register relative
2. add 1
3. Store base register relative

The main overhead would be the registeration of the sequence.

The advantage on x86 is that you do not need a restartable sequence
since a single lockless RMV instruction can do this (this_cpu_inc f.e.)

> One benefit of your proposal is to lessen the number of retired instructions,
> but if we take the IPC into account, it is slower than rseq in my benchmark. What
> benefits do you expect from using segment selectors and non-lock-prefixed atomic
> instructions on the fast-path ?

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.

If cmpxchg local is slower than a group of instructions to do the same
then there is an obvious question to the cpu architects why we would need
the instruction at all (aside from the fact that we do not need a
restartable sequence for these instructions).