----- 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 -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
