lkml.org 
[lkml]   [2012]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] bitops: add _local bitops
    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


    \
     
     \ /
      Last update: 2012-05-09 22:41    [W:2.198 / U:0.536 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site