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 kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
