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

On Sun, 1 Apr 2018, Alan Cox wrote:

quoted

       Restartable sequences are atomic  with  respect  to  preemption
       (making  it atomic with respect to other threads running on the
       same CPU), as well as  signal  delivery  (user-space  execution
       contexts nested over the same thread).

CPU generally means 'big lump with legs on it'. You are not atomic to the
same CPU, because that CPU may have 30+ cores with 8 threads per core.

It could do with some better terminology (hardware thread, CPU context ?)

Well we call it a "CPU" in the scheduler context I think.  We could use
better terminology throughout the kernel tools and source.

Hardware Execution Context?

quoted

       In  a  typical  usage scenario, the thread registering the rseq
       structure will be performing  loads  and  stores  from/to  that
       structure.  It  is  however also allowed to read that structure
       from other threads.  The rseq field updates  performed  by  the
       kernel  provide  relaxed  atomicity  semantics, which guarantee
       that other threads performing relaxed atomic reads of  the  cpu
       number cache will always observe a consistent value.

So what happens to your API if the kernel atomics get improved ? You are
effectively exporting rseq behaviour from private to public.

There is already a pretty complex coherency model guiding kernel atomics.
Improvements/changes to that are difficult and the effect will ripple
throughout the kernel. So I would suggest that these areas of the kernel
are pretty "petrified" (or written in stone).