lkml.org 
[lkml]   [2012]   [Apr]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH v4 06/10] KVM: MMU: fast path of handling guest page fault
    On Sun, Apr 29, 2012 at 05:50:04PM +0900, Takuya Yoshikawa wrote:
    > On Fri, 27 Apr 2012 11:52:13 -0300
    > Marcelo Tosatti <mtosatti@redhat.com> wrote:
    >
    > > Yes but the objective you are aiming for is to read and write sptes
    > > without mmu_lock. That is, i am not talking about this patch.
    > > Please read carefully the two examples i gave (separated by "example)").
    >
    > The real objective is not still clear.
    >
    > The ~10% improvement reported before was on macro benchmarks during live
    > migration. At least, that optimization was the initial objective.
    >
    > But at some point, the objective suddenly changed to "lock-less" without
    > understanding what introduced the original improvement.
    >
    > Was the problem really mmu_lock contention?
    >
    > If the path being introduced by this patch is really fast, isn't it
    > possible to achieve the same improvement still using mmu_lock?

    Right. Supposedly, mmu_lock cacheline bouncing is the problem. Hum:

    $ pahole -C "kvm" /tmp/kvm.ko
    struct kvm {
    spinlock_t mmu_lock; /* 0 2
    */

    /* XXX 6 bytes hole, try to pack */

    struct mutex slots_lock; /* 8 32
    */
    struct mm_struct * mm; /* 40 8
    */
    struct kvm_memslots * memslots; /* 48 8
    */
    struct srcu_struct srcu; /* 56 48
    */
    /* --- cacheline 1 boundary (64 bytes) was 40 bytes ago --- */
    u32 bsp_vcpu_id; /* 104 4
    */

    /* XXX 4 bytes hole, try to pack */

    Oops. False sharing?

    > Note: During live migration, the fact that the guest gets faulted is
    > itself a limitation. We could easily see noticeable slowdown of a
    > program even if it runs only between two GET_DIRTY_LOGs.
    >
    >
    > > The rules for code under mmu_lock should be:
    > >
    > > 1) Spte updates under mmu lock must always be atomic and
    > > with locked instructions.
    > > 2) Spte values must be read once, and appropriate action
    > > must be taken when writing them back in case their value
    > > has changed (remote TLB flush might be required).
    >
    > Although I am not certain about what will be really needed in the
    > final form, if this kind of maybe-needed-overhead is going to be
    > added little by little, I worry about possible regression.
    >
    > Thanks,
    > Takuya

    Yes, that is a possibility.



    \
     
     \ /
      Last update: 2012-05-01 04:41    [W:0.026 / U:30.608 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site