Re: [PATCH] bitops: add _local bitops

["Michael S. Tsirkin" <mst@redhat.com>]

On Wed, May 09, 2012 at 12:19:40PM -0700, Andrew Morton wrote:
> On Wed, 9 May 2012 16:45:29 +0300
> "Michael S. Tsirkin" <mst@redhat.com> 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.
> 
> Well.  It adds more complexity, makes the kernel harder to understand
> and maintain and introduces more opportunities for developers to add
> bugs.  So from that point of view, the best way of handling this patch
> is to delete it.
> 
> Presumably the patch offers some benefit to offest all those costs. 
> But you didn't tell us what that benefit is, so we cannot make
> a decision.
> 
> IOW: numbers, please.  Convincing ones, for realistic test cases.

I can try but in practice it's not an optimization.
What kvm needs is a guarantee that a memory update will be done in a
single instruction.

> Secondly: can KVM just use __set_bit() and friends?  I suspect those
> interfaces happen to meet your requirements.  At least on architectures
> you care about.

Sigh. I started with this, but then Avi Kivity said that he's worried
about someone changing __test_and_clear_bit on x86
such that the change won't be atomic (single instruction) anymore.
So I put inline asm into kvm.c. This drew comment from Peter
that maintaining separate asm code in kvm.c adds too much
maintainance overhead so I should implement _local, add
asm-generic fallback and put it all in generic code.

In practice ATM any of the above will work. We probably don't even need
to add barrier() calls since what we do afterwards is apic access which
has an optimization barrier anyway.  But I'm fine with adding them in
there just in case if that's what people want.

However, since we've come full circle, I'd like to have a discussion
on what, exactly, is acceptable to all maintainers.
Avi, Andrew, Peter, could you please comment?

-- 
MST