Date: Thu, 14 Dec 2017 12:50:13 -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: <12046460.34426.1513275177081.JavaMail.zimbra@efficios.com>
Message-ID: <alpine.DEB.2.20.1712141238180.8340@nuc-kabylake>
References: <20171214161403.30643-1-mathieu.desnoyers@efficios.com> <20171214161403.30643-3-mathieu.desnoyers@efficios.com> <alpine.DEB.2.20.1712141033100.6249@nuc-kabylake> <12046460.34426.1513275177081.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: 1669
Lines: 38

On Thu, 14 Dec 2017, Mathieu Desnoyers wrote:

> > 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.
>
> How would you do it on ARM32 ?

Actually you do not really need RMV instructions. The data is cpu specific
so within a restartable sequence you would have exclusive access right?

F.e. a increment would be

1. Load base register relative
2. add 1
3. Store base register relative

The main overhead would be the registeration of the sequence.

The advantage on x86 is that you do not need a restartable sequence
since a single lockless RMV instruction can do this (this_cpu_inc f.e.)

> One benefit of your proposal is to lessen the number of retired instructions,
> but if we take the IPC into account, it is slower than rseq in my benchmark. What
> benefits do you expect from using segment selectors and non-lock-prefixed atomic
> instructions on the fast-path ?

Ultimately I wish fast increments like done by this_cpu_inc() could be
implemented in an efficient way on non x86 platforms that do not have
cheap instructions like that.

If cmpxchg local is slower than a group of instructions to do the same
then there is an obvious question to the cpu architects why we would need
the instruction at all (aside from the fact that we do not need a
restartable sequence for these instructions).