From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f48.google.com (mail-pa0-f48.google.com [209.85.220.48]) by kanga.kvack.org (Postfix) with ESMTP id 4D4CC6B0156 for ; Thu, 7 Nov 2013 07:50:27 -0500 (EST) Received: by mail-pa0-f48.google.com with SMTP id kq14so555111pab.7 for ; Thu, 07 Nov 2013 04:50:26 -0800 (PST) Received: from psmtp.com ([74.125.245.116]) by mx.google.com with SMTP id cx4si2558268pbc.119.2013.11.07.04.50.25 for ; Thu, 07 Nov 2013 04:50:26 -0800 (PST) Received: by mail-qc0-f174.google.com with SMTP id v1so335491qcw.19 for ; Thu, 07 Nov 2013 04:50:23 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <1383773827.11046.355.camel@schen9-DESK> Date: Thu, 7 Nov 2013 04:50:23 -0800 Message-ID: Subject: Re: [PATCH v3 3/5] MCS Lock: Barrier corrections From: Michel Lespinasse Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org List-ID: To: Linus Torvalds Cc: Waiman Long , Arnd Bergmann , Rik van Riel , Aswin Chandramouleeswaran , "Paul E.McKenney" , Raghavendra K T , "Figo. zhang" , linux-arch@vger.kernel.org, Andi Kleen , Peter Zijlstra , George Spelvin , Tim Chen , Ingo Molnar , Peter Hurley , "H. Peter Anvin" , Andrew Morton , linux-mm , Andrea Arcangeli , Alex Shi , linux-kernel@vger.kernel.org, Scott J Norton , Thomas Gleixner , Dave Hansen , Matthew R Wilcox , Will Deacon , Davidlohr Bueso On Thu, Nov 7, 2013 at 4:06 AM, Linus Torvalds wrote: > > On Nov 7, 2013 6:55 PM, "Michel Lespinasse" wrote: >> >> Rather than writing arch-specific locking code, would you agree to >> introduce acquire and release memory operations ? > > Yes, that's probably the right thing to do. What ops do we need? Store with > release, cmpxchg and load with acquire? Anything else? Depends on what lock types we want to implement on top; for MCS we would need: - xchg acquire (common case) and load acquire (for spinning on our locker's wait word) - cmpxchg release (when there is no next locker) and store release (when writing to the next locker's wait word) One downside of the proposal is that using a load acquire for spinning puts the memory barrier within the spin loop. So this model is very intuitive and does not add unnecessary barriers on x86, but it my place the barriers in a suboptimal place for architectures that need them. -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org