Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753410AbdLNQoj (ORCPT ); Thu, 14 Dec 2017 11:44:39 -0500 Received: from resqmta-ch2-06v.sys.comcast.net ([69.252.207.38]:35642 "EHLO resqmta-ch2-06v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753090AbdLNQoi (ORCPT ); Thu, 14 Dec 2017 11:44:38 -0500 Date: Thu, 14 Dec 2017 10:44:34 -0600 (CST) From: Christopher Lameter X-X-Sender: cl@nuc-kabylake To: Mathieu Desnoyers cc: Peter Zijlstra , "Paul E . McKenney" , Boqun Feng , Andy Lutomirski , Dave Watson , linux-kernel@vger.kernel.org, linux-api@vger.kernel.org, Paul Turner , Andrew Morton , Russell King , Thomas Gleixner , Ingo Molnar , "H . Peter Anvin" , Andrew Hunter , Andi Kleen , Ben Maurer , Steven Rostedt , Josh Triplett , Linus Torvalds , Catalin Marinas , Will Deacon , Michael Kerrisk , Alexander Viro Subject: Re: [RFC PATCH for 4.16 02/21] rseq: Introduce restartable sequences system call (v12) In-Reply-To: <20171214161403.30643-3-mathieu.desnoyers@efficios.com> Message-ID: References: <20171214161403.30643-1-mathieu.desnoyers@efficios.com> <20171214161403.30643-3-mathieu.desnoyers@efficios.com> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-CMAE-Envelope: MS4wfNDJOhn9UO7K26WOH/msJhrBMO27zBMZhuO2JmhDxmUIj1AQy3r9BPlpGKMf7XcDIdE8b7Ha2KggwOESM6lFTIY51fzwVmDqYOfWywzvLhps9A9/cN5J nGA/pvuQEjCCm/AoVPw+DZrCzr4GjKtGQPN6Fcvmq2PMb5BFYi/7Ql2NNWAYixVpBNosfbb71YdqGmowaU322ZWmdTEAxk4zViK+cOYeQPfoSFbPPtUHgv++ XlFFR1dpAeqKOCoGak8KBrRtHLgD9YEiypji22um8lqL9paRCGP9uXMn16Mx1n2Pabw3T9smaE9OE1M1Zp8Lcf0yz9EIbVmB3SD9cC2lihLQ5G1jhTqBmKfF RoXY/vfK6H/klR2Jbl42GE4ial2UJvt3uTjAW0KH1ghJFwQO0REjprgRNMmT6Jcgt+V5XyKtEdBZBortL7vm6WfsSuSLz2tPFhP//Gi2OSj5/MHJiC7n7pPo x/2RZ9hA6McTSM8CcejgtCU4da3B1zLW9WayZqOFPUrCqXLmssMAAdaD/mICYfDmxY7dmMmgGOvHX4qnGOfv9/yC06XZ0JCrPr8HgVGjdwqrb6fAXzxgZ9xW 9I6EoyDas20rwhIO2+yddqH9xfVJQswdjC+dVh7CK8UDobsow4hp7kE3JXcJolWD9mjQ3r9PH2bHUkeZSxfFZZbafYzbwVLnnlxFMWn2ezljjo7czDXppz1+ paFBWLYOippVNlZCVrxevqOk8FMVEnAqNA+t0L4mKPwzz3ynhvMVsR61QNpErD9BiQQ/Q96Ex0a0VMGbp8EpheOX3f6YImnrKm8Rwnb574J7xyNxAKoxkcdW zNdNGPdPahe9/0/c99sq8YNkXIa/AYlt1rhQlHVbJnOjseviSRQDUK/9DACfGgoahutes7OhB6xsSpzspw8= Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1226 Lines: 25 On Thu, 14 Dec 2017, Mathieu Desnoyers wrote: > On x86, yet another possible approach would be to use the gs segment > selector to point to user-space per-cpu data. This approach performs > similarly to the cpu id cache, but it has two disadvantages: it is > not portable, and it is incompatible with existing applications already > using the gs segment selector for other purposes. 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. In a restartable sequence you could increase efficieny by avoiding full atomic instructions. This would be similar to the lockless RMV available on x86 then. And in that form it is portable. A context switch to another processors would mean that the value of the base register has changed and that we therefore are accessing another per cpu segment. Restarting the sequence will yield a correct result without any reloading of registers.