Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751860AbbFYCzV (ORCPT ); Wed, 24 Jun 2015 22:55:21 -0400 Received: from mail-wi0-f170.google.com ([209.85.212.170]:37476 "EHLO mail-wi0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751057AbbFYCzM (ORCPT ); Wed, 24 Jun 2015 22:55:12 -0400 MIME-Version: 1.0 In-Reply-To: References: <20150624222609.6116.86035.stgit@kitami.mtv.corp.google.com> From: Paul Turner Date: Wed, 24 Jun 2015 19:54:41 -0700 Message-ID: Subject: Re: [RFC PATCH 0/3] restartable sequences: fast user-space percpu critical sections To: Andy Lutomirski Cc: Peter Zijlstra , "Paul E. McKenney" , Mathieu Desnoyers , Andrew Hunter , Andi Kleen , Lai Jiangshan , Linux API , "linux-kernel@vger.kernel.org" , Steven Rostedt , Josh Triplett , Ingo Molnar , Andrew Morton , Linus Torvalds , Chris Lameter Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2352 Lines: 51 On Wed, Jun 24, 2015 at 5:07 PM, Andy Lutomirski wrote: > On Wed, Jun 24, 2015 at 3:26 PM, Paul Turner wrote: >> This is a fairly small series demonstrating a feature we've found to be quite >> powerful in practice, "restartable sequences". >> > > On an extremely short glance, I'm starting to think that the right > approach, at least for x86, is to implement per-cpu gsbase. Then you > could do cmpxchg with a gs prefix to atomically take a percpu lock and > atomically release a percpu lock and check whether someone else stole > the lock from you. (Note: cmpxchg, unlike lock cmpxchg, is very > fast.) > > This is totally useless for other architectures, but I think it would > be reasonable clean on x86. Thoughts? So this gives semantics that are obviously similar to this_cpu(). This provides allows reasonable per-cpu counters (which is alone almost sufficient for a strong user-space RCU implementation giving this some legs). However, unless there's a nice implementation trick I'm missing, the thing that stands out to me for locks (or other primitives) is that this forces a two-phase commit. There's no way (short of say, cmpxchg16b) to perform a write conditional on the lock not having been stolen from us (and subsequently release the lock). e.g. 1) We take the operation in some sort of speculative mode, that another thread on the same cpu is stilled allowed to steal from us 2) We prepare what we want to commit 3) At this point we have to promote the lock taken in (1) to perform our actual commit, or see that someone else has stolen (1) 4) Release the promoted lock in (3) However, this means that if we're preempted at (3) then no other thread on that cpu can make progress until we've been rescheduled and released the lock; a nice property of the model we have today is that threads sharing a cpu can not impede each other beyond what the scheduler allows. A lesser concern, but worth mentioning, is that there are also potential pitfalls in the interaction with signal handlers, particularly if a 2-phase commit is used. - Paul -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/