On Fri, Jul 22, 2022, Mingwei Zhang wrote: > On Fri, Apr 29, 2022, Yosry Ahmed wrote: > > Count the pages used by KVM mmu on x86 for in secondary pagetable stats. > > > > For the legacy mmu, accounting pagetable stats is combined KVM's > > existing for mmu pages in newly introduced kvm_[un]account_mmu_page() > > helpers. > > > > For tdp mmu, introduce new tdp_[un]account_mmu_page() helpers. That > > combines accounting pagetable stats with the tdp_mmu_pages counter > > accounting. > > > > tdp_mmu_pages counter introduced in this series [1]. This patch was > > rebased on top of the first two patches in that series. > > > > [1]https://lore.kernel.org/lkml/20220401063636.2414200-1-mizhang@xxxxxxxxxx/ > > > > Signed-off-by: Yosry Ahmed <yosryahmed@xxxxxxxxxx> > > --- > > It looks like there are two metrics for mmu in x86: one for shadow mmu > and the other for TDP mmu. Is there any plan to merge them together? There aren't two _separate_ metrics per se, rather that the TDP MMU (intentionally) doesn't honor KVM_SET_NR_MMU_PAGES, nor does it play nice the the core mm shrinkers. Thus, the TDP MMU doesn't udpate kvm_mod_used_mmu_pages(), which feeds into both of those things. Long term, I don't think the TDP MMU will ever honor KVM_SET_NR_MMU_PAGES. That particular knob predates proper integration with memcg and probably should be deprecated. As for supporting shrinkers in the TDP MMU, it's unclear whether or not that's truly necessary. And until mmu_shrink_scan() is made a _lot_ smarter, it's somewhat of a moot point because KVM's shrinker implementation is just too naive for it to be a net positive, e.g. it tends to zap upper level entries and wipe out large swaths of KVM's page tables. KVM_SET_NR_MMU_PAGES uses the same naive algorithm, so it's not any better. _______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
