[lkml]   [2012]   [Mar]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 3/4 changelog-v2] KVM: Switch to srcu-less get_dirty_log()
    Marcelo Tosatti <> wrote:

    > > If we do not mind scanning the bitmap twice, we can decouple the
    > > xchg loop and write protection, but it will be a bit slower, and in
    > > any case we need to hold mmu_lock until TLB is flushed.
    > Why is it necessary to scan twice? Simply continuing to the next set
    > of pages, after dropping the lock, should be enough.

    We cannot drop the lock.
    Do you mean doing TLB flush each time before dropping the lock?

    > The potential problem i am referring to is:
    > - kvm.git next + srcu-less series
    > average(ns) stdev ns/page pages improvement(%)
    > 8497356.4 16441.0 32.4 256K -29
    > So 8ms for 1GB. Assuming it increases linearly, it would take
    > 400ms for get_dirty on a 50GB slot (most of that time spent
    > with mmu_lock held). Is this correct?

    Partly yes: my method mainly depends on the number of dirty pages,
    not slot size.

    But it is not a new problem: traversing all shadow pages for that
    also takes linearly increasing time.

    If that 1GB dirty memory is in a 50GB slot, my method will alleviate
    the latency really a lot compared to the current way. I do not want
    to imagine checking every shadow page in such a huge slot.

    Checking pages found in the dirty bitmap only should be better.


     \ /
      Last update: 2012-03-06 16:25    [W:0.022 / U:88.984 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site