On Wed, Mar 07, 2012 at 12:23:17AM +0900, Takuya Yoshikawa wrote: > Marcelo Tosatti <mtosatti@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
