RFC rework KVM mmu_shrink() code
Get series with b4
b4 am [email protected]Versions newest first
- v1 RFC Latest9 patches 21 repliesIn review
Patches in v1 No applies recorded yet
| # | Subject and files | Size | Replies | Applied |
|---|---|---|---|---|
| 1/9 | abstract kvm x86 mmu->n_free_mmu_pagesarch/ arch/ | +9 | 1 reply | |
| 2/9 | rename x86 kvm->arch.n_alloc_mmu_pagesarch/ arch/ arch/ | +6 | 0 replies | |
| 3/9 | replace x86 kvm n_free_mmu_pages with n_used_mmu_pagesarch/ arch/ arch/ | +13 | 2 replies | |
| 4/9 | create aggregate kvm_total_used_mmu_pages valuearch/ | +23 | 5 replies | |
| 5/9 | break out some mmu_skrink() codearch/ | +25 | 0 replies | |
| 6/9 | remove kvm_freed variablearch/ | +5 | 0 replies | |
| 7/9 | make kvm_get_kvm() more robustinclude/ virt/ | +30 | 0 replies | |
| 8/9 | reduce kvm_lock hold times in mmu_skrink()arch/ kernel/ | +40 | 1 reply | |
| 9/9 | make kvm mmu shrinker more aggressivearch/ | +6 | 9 replies |
Reviews trailers per patch
No Reviewed-by, Acked-by or Tested-by trailers for v1 yet.
Cover letter [RFC][PATCH 0/9] rework KVM mmu_shrink() code
This is a big RFC for the moment. These need a bunch more runtime testing.
--
We've seen contention in the mmu_shrink() function. This patch set reworks it to hopefully be more scalable to large numbers of CPUs, as well as large numbers of running VMs.
The patches are ordered with increasing invasiveness.
These seem to boot and run fine. I'm running about 40 VMs at once, while doing "echo 3 > /proc/sys/vm/drop_caches", and killing/restarting VMs constantly.
Seems to be relatively stable, and seems to keep the numbers of kvm_mmu_page_header objects down.