Messages in this thread |  | | | Date | Tue, 6 Mar 2012 12:28:50 -0300 | | From | Marcelo Tosatti <> | | Subject | Re: [PATCH 3/4 changelog-v2] KVM: Switch to srcu-less get_dirty_log() |
| |
On Wed, Mar 07, 2012 at 12:23:17AM +0900, Takuya Yoshikawa wrote: > Marcelo Tosatti <mtosatti@redhat.com> 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?
Yes, only if there is contention (see cond_resched_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.
It was not necessary to read the bitmap under mmu_lock previously.
> 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. > > Takuya
|  |