From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755331AbcHDFBo (ORCPT ); Thu, 4 Aug 2016 01:01:44 -0400 Received: from mail-ua0-f180.google.com ([209.85.217.180]:33400 "EHLO mail-ua0-f180.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751138AbcHDFBm (ORCPT ); Thu, 4 Aug 2016 01:01:42 -0400 MIME-Version: 1.0 In-Reply-To: References: <1469135662-31512-1-git-send-email-mathieu.desnoyers@efficios.com> <1469135662-31512-2-git-send-email-mathieu.desnoyers@efficios.com> <1806206514.82247.1469502139408.JavaMail.zimbra@efficios.com> <20160803122717.GL6862@twins.programming.kicks-ass.net> From: Andy Lutomirski Date: Wed, 3 Aug 2016 22:01:20 -0700 Message-ID: Subject: Re: [RFC PATCH v7 1/7] Restartable sequences system call To: Christoph Lameter Cc: Ben Maurer , Thomas Gleixner , Ingo Molnar , Russell King , linux-api , Andrew Morton , Michael Kerrisk , Dave Watson , rostedt , Will Deacon , Linus Torvalds , Mathieu Desnoyers , "Paul E. McKenney" , Andi Kleen , Josh Triplett , Paul Turner , Boqun Feng , "linux-kernel@vger.kernel.org" , Catalin Marinas , Andrew Hunter , "H. Peter Anvin" , Peter Zijlstra Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Aug 3, 2016 11:31 AM, "Christoph Lameter" wrote: > > On Wed, 3 Aug 2016, Andy Lutomirski wrote: > > > > Well, a CMPXCHG without LOCK prefix isn't all that expensive on x86. > > > > > > It is however on PPC and possibly other architectures, so in name of > > > simplicity supporting only the one variant makes sense. > > > > > > > I wouldn't want to depend on CMPXCHG. But imagine we had primitives > > that were narrower than the full abort-on-preemption primitive. > > Specifically, suppose we had abort if (actual cpu != expected_cpu || > > *aptr != aval). We could do things like: > > > > The latency issues that are addressed by restartable sequences require > minimim instruction overhead. Lockless CMPXCHG is very important in that > area and I would not simply remove it from consideration. What I mean is: I think the solution shouldn't depend on the x86-specific unlocked CMPXCHG instruction if it can be avoided.