KVM: MMU: support pte prefetch when intercepted guest #PF
cover KVM: MMU: support pte prefetch when intercepted guest #PF
Hi Avi, Marcelo,
This patchset support pte prefetch when intercepted guest #PF, the aim is to reduce guest #PF which can be intercepted by VMM.
If we meet any failure in the prefetch path, we will exit it and not try other ptes to avoid become heavy path.
During my performance test, under EPT enabled case, unixbench shows the performance improved ~1.2%, user EPT disable case, unixbench shows the performance improved ~3.6%
Quoted 10 lines · Xiao Guangrong
Hi Avi, Marcelo,
This patchset support pte prefetch when intercepted guest #PF, the aim is to reduce guest #PF which can be intercepted by VMM.
If we meet any failure in the prefetch path, we will exit it and not try other ptes to avoid become heavy path.
During my performance test, under EPT enabled case, unixbench shows the performance improved ~1.2%,
Once the guest has faulted in all memory, we shouldn't see much improvement, yes?
Quoted 3 lines
user EPT disable case,
unixbench shows the performance improved ~3.6%
I'm a little worried about this. In some workloads, prefetch can often fail due to gpte.a=0 so we spend effort doing nothing. There is also the issue of marking pages as accessed or even dirty when in fact the guest did not access them.
We should map those pages with pte.a=pte.d=0 so we don't confuse host memory management. On EPT (which lacks a/d bits) we can't enable it (but we can on NPT).
Signature · 1 line
error compiling committee.c: too many arguments to function
Quoted 6 lines · Avi Kivity
Quoted 5 lines · Xiao Guangrong
Hi Avi, Marcelo,
This patchset support pte prefetch when intercepted guest #PF, the aim is to reduce guest #PF which can be intercepted by VMM.
Quoted 8 lines
Quoted 5 lines
If we meet any failure in the prefetch path, we will exit it and not try other ptes to avoid become heavy path.
During my performance test, under EPT enabled case, unixbench shows the performance improved ~1.2%,
Once the guest has faulted in all memory, we shouldn't see much improvement, yes?
I think you are right, this path only prefetch valid/pte.A=1 mapping.
Quoted 7 lines
Quoted 4 lines
user EPT disable case,
unixbench shows the performance improved ~3.6%I'm a little worried about this. In some workloads, prefetch can often fail due to gpte.a=0 so we spend effort doing nothing.
Yes, prefetch is not alway success, but the prefetch path is fast, it not cost much time, at the worst case, only 128 bytes we need read form guest pte. Once it's successful, much overload can be reduce.
Quoted 9 lines
There is also
the issue of marking pages as accessed or even dirty when in fact the guest did not access them.We should map those pages with pte.a=pte.d=0 so we don't confuse host memory management. On EPT (which lacks a/d bits) we can't enable it (but we can on NPT).
You are right, this is the speculative path.
For the pte.A bit:
we called mmu_set_spte() with speculative = true, so we set pte.a = 0 in this path.
For the pte.D bit:
We should fix also set pte.d = 0 in speculative path, the same problem is in invlpg/pte write path, will do it in the next version.
Quoted 13 lines · Xiao Guangrong
Quoted 10 lines · Avi Kivity
Quoted 8 lines · Xiao Guangrong
Hi Avi, Marcelo,
This patchset support pte prefetch when intercepted guest #PF, the aim is to reduce guest #PF which can be intercepted by VMM.
If we meet any failure in the prefetch path, we will exit it and not try other ptes to avoid become heavy path.
Quoted 8 lines
Quoted 6 lines
Quoted 3 lines
During my performance test, under EPT enabled case, unixbench shows the performance improved ~1.2%,
Once the guest has faulted in all memory, we shouldn't see much improvement, yes?
I think you are right, this path only prefetch valid/pte.A=1 mapping.
I mean for tdp. Faulting is rare once the guest has touched all of memory.
Quoted 11 lines
Quoted 7 lines
Quoted 4 lines
user EPT disable case,
unixbench shows the performance improved ~3.6%I'm a little worried about this. In some workloads, prefetch can often fail due to gpte.a=0 so we spend effort doing nothing.
Yes, prefetch is not alway success, but the prefetch path is fast, it not cost much time, at the worst case, only 128 bytes we need read form guest pte. Once it's successful, much overload can be reduce.
Ok.
Quoted 7 lines
Quoted 5 lines
We should map those pages with pte.a=pte.d=0 so we don't confuse host memory management. On EPT (which lacks a/d bits) we can't enable it (but we can on NPT).
You are right, this is the speculative path.
Quoted 8 lines
For the pte.A bit:
we calledmmu_set_spte()with speculative = true, so we set pte.a = 0 in this path.For the pte.D bit:
We should fix also set pte.d = 0 in speculative path, the same problem is in invlpg/pte write path, will do it in the next version.
It's not enough to set spte.d=0, we also need to sample it later.
Signature · 1 line
error compiling committee.c: too many arguments to function