Avi Kivity wrote:
On 07/06/2010 01:49 PM, Xiao Guangrong wrote:Umm, before post this patchset, i have done the draft performance test for
Introduce this function to topup prefetch cacheLet's make it 8 to start with... It's frightening enough.
diff --git a/arch/x86/kvm/mmu.c b/arch/x86/kvm/mmu.c
index 3dcd55d..cda4587 100644
--- a/arch/x86/kvm/mmu.c
+++ b/arch/x86/kvm/mmu.c
@@ -89,6 +89,8 @@ module_param(oos_shadow, bool, 0644);
}
#endif
+#define PTE_PREFETCH_NUM 16
(8 = one cache line in both guest and host)
different prefetch distance, and it shows 16 is the best distance that we can
get highest performance.
Umm, but at the worst case, we should allocate 40 items for rmap, it's heavy+static int pte_prefetch_topup_memory_cache(struct kvm_vcpu *vcpu)Just make the ordinary topup sufficient for prefetch. If we allocate
+{
+ return __mmu_topup_memory_cache(&vcpu->arch.mmu_rmap_desc_cache,
+ rmap_desc_cache, PTE_PREFETCH_NUM,
+ PTE_PREFETCH_NUM, GFP_ATOMIC);
+}
+
too much, we don't lose anything, the memory remains for the next time
around.
for GFP_ATOMIC allocation and holding mmu_lock.