Date: Fri, 15 Dec 2017 11:13:00 -0600 (CST)
From: Christopher Lameter <cl@linux.com>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
cc: Peter Zijlstra <peterz@infradead.org>,
        "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
        Boqun Feng <boqun.feng@gmail.com>,
        Andy Lutomirski <luto@amacapital.net>,
        Dave Watson <davejwatson@fb.com>,
        linux-kernel <linux-kernel@vger.kernel.org>,
        linux-api <linux-api@vger.kernel.org>, Paul Turner <pjt@google.com>,
        Andrew Morton <akpm@linux-foundation.org>,
        Russell King <linux@arm.linux.org.uk>,
        Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>,
        "H. Peter Anvin" <hpa@zytor.com>, Andrew Hunter <ahh@google.com>,
        Andi Kleen <andi@firstfloor.org>, Ben Maurer <bmaurer@fb.com>,
        rostedt <rostedt@goodmis.org>, Josh Triplett <josh@joshtriplett.org>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will.deacon@arm.com>,
        Michael Kerrisk <mtk.manpages@gmail.com>,
        Alexander Viro <viro@zeniv.linux.org.uk>
Subject: Re: [RFC PATCH for 4.16 02/21] rseq: Introduce restartable sequences
 system call (v12)
In-Reply-To: <729438855.35910.1513356742518.JavaMail.zimbra@efficios.com>
Message-ID: <alpine.DEB.2.20.1712151103050.26844@nuc-kabylake>
References: <20171214161403.30643-1-mathieu.desnoyers@efficios.com> <alpine.DEB.2.20.1712141033100.6249@nuc-kabylake> <12046460.34426.1513275177081.JavaMail.zimbra@efficios.com> <alpine.DEB.2.20.1712141238180.8340@nuc-kabylake>
 <1537392285.34532.1513279478488.JavaMail.zimbra@efficios.com> <alpine.DEB.2.20.1712141512360.8945@nuc-kabylake> <20171214212023.GJ3326@worktop> <alpine.DEB.2.20.1712150903490.14235@nuc-kabylake> <729438855.35910.1513356742518.JavaMail.zimbra@efficios.com>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 872
Lines: 19

On Fri, 15 Dec 2017, Mathieu Desnoyers wrote:

> 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.

fs/gs seems to be reserved for thread local storage. So it would
be shared in user space like the corresponding cpu segment register in
kernel space where multiple subsystems share %gs.

The same can be done in user space. Ulrich Drepper has a writeup on this

https://www.akkadia.org/drepper/tls.pdf

Savings in execution time could come about because there would not be the
need to determine the address of the processor specific memory area in
each restartable sequence and there would be memory free of contention for
such a sequence in order f.e. to realize fast counters.