Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752764Ab2EMKss (ORCPT ); Sun, 13 May 2012 06:48:48 -0400 Received: from mx1.redhat.com ([209.132.183.28]:1026 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751739Ab2EMKsq (ORCPT ); Sun, 13 May 2012 06:48:46 -0400 Message-ID: <4FAF917A.1080904@redhat.com> Date: Sun, 13 May 2012 13:48:26 +0300 From: Avi Kivity User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:12.0) Gecko/20120430 Thunderbird/12.0.1 MIME-Version: 1.0 To: "Michael S. Tsirkin" CC: Christoph Lameter , "H. Peter Anvin" , 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, Marcelo Tosatti , Linus Torvalds Subject: Re: [PATCHv2] bitops: add _local bitops References: <20120509162819.GA21328@redhat.com> <4FAF8941.2010308@redhat.com> <20120513104502.GD23273@redhat.com> In-Reply-To: <20120513104502.GD23273@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1880 Lines: 48 On 05/13/2012 01:45 PM, Michael S. Tsirkin wrote: > On Sun, May 13, 2012 at 01:13:21PM +0300, Avi Kivity wrote: > > On 05/10/2012 10:04 PM, Christoph Lameter wrote: > > > On Wed, 9 May 2012, Michael S. Tsirkin wrote: > > > > > > > kvm needs to update some hypervisor variables atomically > > > > in a sense that the operation can't be interrupted > > > > in the middle. However the hypervisor always runs > > > > on the same CPU so it does not need any memory > > > > barrier or lock prefix. > > > > > > > > Add _local bitops for this purpose: define them > > > > as non-atomics for x86 and (for now) atomics for > > > > everyone else. > > > > > > Have you tried to use the this_cpu_ops for that purpose? They create the > > > per cpu atomic instructions that you want without a lock prefix and can > > > also relocate the per cpu pointer to the correct processor via a > > > segment register prefix. > > > > > > There are no bit operations provided right now but those can either be > > > improvised using this_cpu_cmpxchg or added. > > > > this_cpu_xchg() should be sufficient, since only bit zero has any > > meaning in our use case (so xchg with zero is equivalent to > > test_and_clear_bit). > > Yes it should work. No idea how it'd perform: > arch/x86/include/asm/percpu.h implies it's expensive. It says a naive implementation is expensive, whereas the implementation actually used (a cmpxchg loop) is better. > My latest version > simply documents what __test_and_clear does anyway. > Which was indicated is acceptable ... > Did you change your mind? No. -- error compiling committee.c: too many arguments to function -- 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/