From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) by kanga.kvack.org (Postfix) with ESMTP id D17F66B0031 for ; Fri, 22 Nov 2013 14:06:42 -0500 (EST) Received: by mail-ve0-f170.google.com with SMTP id oy12so1267231veb.1 for ; Fri, 22 Nov 2013 11:06:42 -0800 (PST) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [2607:f8b0:400c:c02::22d]) by mx.google.com with ESMTPS id tq4si13016162vdc.103.2013.11.22.11.06.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 11:06:41 -0800 (PST) Received: by mail-vb0-f45.google.com with SMTP id p14so1139265vbm.4 for ; Fri, 22 Nov 2013 11:06:41 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20131122184937.GX4138@linux.vnet.ibm.com> References: <20131120214402.GM4138@linux.vnet.ibm.com> <1384991514.11046.504.camel@schen9-DESK> <20131121045333.GO4138@linux.vnet.ibm.com> <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> Date: Fri, 22 Nov 2013 11:06:41 -0800 Message-ID: Subject: Re: [PATCH v6 4/5] MCS Lock: Barrier corrections From: Linus Torvalds Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Paul McKenney 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 10:49 AM, Paul E. McKenney wrote: > > You see, my problem is not the "crazy ordering" DEC Alpha, Itanium, > PowerPC, or even ARM. It is really obvious what instructions to use in > a stiffened-up smp_store_release() for those guys: "mb" for DEC Alpha, > "st.rel" for Itanium, "sync" for PowerPC, and "dmb" for ARM. Believe it > or not, my problem is instead with good old tightly ordered x86. > > We -could- just put an mfence into x86's smp_store_release() and > be done with it Why would you bother? The *acquire* has a memory barrier. End of story. On x86, it has to (since otherwise a load inside the locked region could be re-ordered wrt the write that takes the lock). Basically, any time you think you need to add a memory barrier on x86, you should go "I'm doing something wrong". It's that simple. 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