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

[Mathieu Desnoyers]

----- On Dec 15, 2017, at 10:05 AM, Chris Lameter cl@xxxxxxxxx wrote:

> On Thu, 14 Dec 2017, Peter Zijlstra wrote:
> 
>> > But my company has extensive user space code that maintains a lot of
>> > counters and does other tricks to get full performance out of the
>> > hardware. Such a mechanism would also be good from user space. Why keep
>> > the good stuff only inside the kernel?
>>
>> Mathieu's proposal is for userspace, _only_ userspace.
> 
> But what we were talking about are instructions that work effectively in
> kernel space whose efficiency restartable sequences could bring to user
> space.

It can be worthwhile to recap my understanding of this thread so far:

AFAIU, Chris' proposal is to use the "gs" segment selector as instruction
prefix on x86 rather than explicitly loading CPU number and calculating
offsets.

This can turn sequences of rseq operations like this cmpxchg:

Registers:

  R1: return value
  R2: expected value
  R3: new value
  R4: cpu_id

rseq cmpxchg:

  load TLS::cpu_id_start into R4
  calculate offset of v
  fs:mov (store rseq descriptor address into TLS::rseq_cs)
  compare R4 against TLS::cpu_id
  jne abort
  mov (load v into R1)
  compare R1 against R2
  jne cmpfail
  mov (store R3 into *v)

into:

  fs:mov (store rseq descriptor address into TLS::rseq_cs)
  gs:mov (load *v+off into R1)
  compare R1 against R2
  jne cmpfail
  gs:mov (store R3 into *v+off)

My first concern with this approach is the lack of flexibility of the segment
selector method wrt variety of schemes user-space has to deal with for memory
allocation. In the kernel, this is achieved by ensuring that all per-cpu data
layout is segment-selector-prefix friendly.

Another aspect that worries me is applications using the gs segment selector
for other purposes. Suddenly reserving the gs segment selector for use by a
library like glibc may lead to incompatibilities with applications already
using it.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com