Re: [PATCH v2 00/16] KVM: MMU: fast page fault

From: Takuya Yoshikawa
Date: Fri Apr 13 2012 - 23:38:04 EST


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 linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/