On Fri, 13 Apr 2012 18:05:29 +0800 Xiao Guangrong <xiaoguangrong@xxxxxxxxxxxxxxxxxx> wrote: > Thanks for Avi and Marcelo's review, i have simplified the whole things > in this version: > - it only fix the page fault with PFEC.P = 1 && PFEC.W = 0 that means > unlock set_spte path can be dropped. > > - it only fixes the page fault caused by dirty-log > > In this version, all the information we need is from spte, the > SPTE_ALLOW_WRITE bit and SPTE_WRITE_PROTECT bit: > - SPTE_ALLOW_WRITE is set if the gpte is writable and the pfn pointed > by the spte is writable on host. > - SPTE_WRITE_PROTECT is set if the spte is write-protected by shadow > page table protection. > > All these bits can be protected by cmpxchg, now, all the things is fairly > simple than before. :) Well, could you remove cleanup patches not needed for "lock-less" from this patch series? I want to see them separately. Or everything was needed for "lock-less" ? > Performance test: > > autotest migration: > (Host: Intel(R) Xeon(R) CPU X5690 @ 3.47GHz * 12 + 32G) Please explain what this test result means, not just numbers. There are many aspects: - how fast migration can converge/complete - how fast programs inside the guest can run during migration: -- throughput -- latency - ... I think lock-less will reduce latency a lot, but not sure about convergence: why it became fast? > - For ept: > > Before: > smp2.Fedora.16.64.migrate > Times .unix .with_autotest.dbench.unix total > 1 104 214 323 > 2 68 238 310 > 3 68 242 314 > > After: > smp2.Fedora.16.64.migrate > Times .unix .with_autotest.dbench.unix total > 1 101 190 295 > 2 67 188 259 > 3 66 217 289 > As discussed on v1-threads, the main goal of this "lock-less" should be the elimination of mmu_lock contentions. So what we should measure is latency. Thanks, 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
