From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by kanga.kvack.org (Postfix) with ESMTP id EF2D16B0031 for ; Fri, 22 Nov 2013 15:37:45 -0500 (EST) Received: by mail-ob0-f181.google.com with SMTP id uy5so1825603obc.26 for ; Fri, 22 Nov 2013 12:37:45 -0800 (PST) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com. [32.97.110.154]) by mx.google.com with ESMTPS id r7si22707571oem.19.2013.11.22.12.37.44 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 22 Nov 2013 12:37:45 -0800 (PST) Received: from /spool/local by e36.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 22 Nov 2013 13:37:44 -0700 Received: from b03cxnp08025.gho.boulder.ibm.com (b03cxnp08025.gho.boulder.ibm.com [9.17.130.17]) by d03dlp02.boulder.ibm.com (Postfix) with ESMTP id AB2FB3E40040 for ; Fri, 22 Nov 2013 13:37:41 -0700 (MST) Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by b03cxnp08025.gho.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rAMIZrCm6095196 for ; Fri, 22 Nov 2013 19:35:53 +0100 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id rAMKeYv8020204 for ; Fri, 22 Nov 2013 13:40:35 -0700 Date: Fri, 22 Nov 2013 12:37:38 -0800 From: "Paul E. McKenney" Subject: Re: [PATCH v6 4/5] MCS Lock: Barrier corrections Message-ID: <20131122203738.GC4138@linux.vnet.ibm.com> Reply-To: paulmck@linux.vnet.ibm.com References: <20131121225208.GJ4138@linux.vnet.ibm.com> <20131122040856.GK4138@linux.vnet.ibm.com> <20131122062314.GN4138@linux.vnet.ibm.com> <20131122151600.GA14988@gmail.com> <20131122184937.GX4138@linux.vnet.ibm.com> <20131122200620.GA4138@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Linus Torvalds Cc: Ingo Molnar , Tim Chen , Will Deacon , Ingo Molnar , Andrew Morton , Thomas Gleixner , "linux-kernel@vger.kernel.org" , linux-mm , "linux-arch@vger.kernel.org" , Waiman Long , Andrea Arcangeli , Alex Shi , Andi Kleen , Michel Lespinasse , Davidlohr Bueso , Matthew R Wilcox , Dave Hansen , Peter Zijlstra , Rik van Riel , Peter Hurley , Raghavendra K T , George Spelvin , "H. Peter Anvin" , Arnd Bergmann , Aswin Chandramouleeswaran , Scott J Norton , "Figo.zhang" On Fri, Nov 22, 2013 at 12:09:31PM -0800, Linus Torvalds wrote: > On Fri, Nov 22, 2013 at 12:06 PM, Paul E. McKenney > wrote: > > > > I am sorry, but that is not always correct. For example, in the contended > > case for Tim Chen's MCS queued locks, the x86 acquisition-side handoff > > code does -not- contain any stores or memory-barrier instructions. > > So? In order to get *into* that contention code, you will have to go > through the fast-case code. Which will contain a locked instruction. So you must also maintain ordering against the critical section that just ended on some other CPU. And that just-ended critical section might well have started -after- you passed through your own fast-case code. In that case, the barriers in your fast-case code cannot possibly help you. Instead, ordering must be supplied by the code in the two handoff code sequences. And in the case of the most recent version of Tim Chen's MCS lock on x86, the two handoff code sequences (release and corresponding acquire) contain neither atomic instructions nor memory-barrier instructions. The weird thing is that it looks like those two handoff code sequences nevertheless provide the unlock+lock guarantee on x86. But I need to look at it some more, and eventually run it by experts from Intel and AMD. Thanx, Paul > So I repeat: a "lock" sequence will always be a memory barrier on x86. > > Linus > -- 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