From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: [PATCH] bitops: add _local bitops Date: Wed, 09 May 2012 09:24:41 -0700 Message-ID: <4FAA9A49.8080900@zytor.com> References: <20120509134528.GA18044@redhat.com> <4FAA7939.6040706@zytor.com> <20120509154734.GB20867@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20120509154734.GB20867@redhat.com> Sender: linux-doc-owner@vger.kernel.org To: "Michael S. Tsirkin" Cc: Rob Landley , Thomas Gleixner , Ingo Molnar , x86@kernel.org, Arnd Bergmann , Andrew Morton , David Howells , Akinobu Mita , Alexey Dobriyan , Herbert Xu , Stephen Rothwell , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Gleb Natapov , Paolo Bonzini , kvm@vger.kernel.org, Avi Kivity , Marcelo Tosatti , Linus Torvalds List-Id: linux-arch.vger.kernel.org On 05/09/2012 08:47 AM, Michael S. Tsirkin wrote: > > By the way, clear_bit on x86 does not seem to contain > an optimization barrier - is my reading correct? > Lock prefix does not affect the compiler, right? Yes, as it clearly states in the comment: * clear_bit() is atomic and may not be reordered. However, it does * not contain a memory barrier, so if it is used for locking purposes, * you should call smp_mb__before_clear_bit() and/or smp_mb__after_clear_bit() * in order to ensure changes are visible on other processors. There is clear_bit_unlock() which has the barrier semantics. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from terminus.zytor.com ([198.137.202.10]:42172 "EHLO mail.zytor.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760056Ab2EIQZC (ORCPT ); Wed, 9 May 2012 12:25:02 -0400 Message-ID: <4FAA9A49.8080900@zytor.com> Date: Wed, 09 May 2012 09:24:41 -0700 From: "H. Peter Anvin" MIME-Version: 1.0 Subject: Re: [PATCH] bitops: add _local bitops References: <20120509134528.GA18044@redhat.com> <4FAA7939.6040706@zytor.com> <20120509154734.GB20867@redhat.com> In-Reply-To: <20120509154734.GB20867@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Sender: linux-arch-owner@vger.kernel.org List-ID: To: "Michael S. Tsirkin" Cc: Rob Landley , Thomas Gleixner , Ingo Molnar , x86@kernel.org, Arnd Bergmann , Andrew Morton , David Howells , Akinobu Mita , Alexey Dobriyan , Herbert Xu , Stephen Rothwell , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Gleb Natapov , Paolo Bonzini , kvm@vger.kernel.org, Avi Kivity , Marcelo Tosatti , Linus Torvalds Message-ID: <20120509162441.hpD9G7T0XNbcj0NevwyUGxQ3dFT1cm7kMl3nuVa2KIA@z> On 05/09/2012 08:47 AM, Michael S. Tsirkin wrote: > > By the way, clear_bit on x86 does not seem to contain > an optimization barrier - is my reading correct? > Lock prefix does not affect the compiler, right? Yes, as it clearly states in the comment: * clear_bit() is atomic and may not be reordered. However, it does * not contain a memory barrier, so if it is used for locking purposes, * you should call smp_mb__before_clear_bit() and/or smp_mb__after_clear_bit() * in order to ensure changes are visible on other processors. There is clear_bit_unlock() which has the barrier semantics. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.