linux-kernel - Re: [PATCH 1/2] KVM: x86/mmu: Change KVM mmu shrinker to no-op

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <ZvSiwc9UFFVIh8Kb@google.com>
Date: Wed, 25 Sep 2024 16:54:41 -0700
From: David Matlack <dmatlack@...gle.com>
To: Vipin Sharma <vipinsh@...gle.com>
Cc: seanjc@...gle.com, pbonzini@...hat.com, zhi.wang.linux@...il.com,
	weijiang.yang@...el.com, mizhang@...gle.com,
	liangchen.linux@...il.com, kvm@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] KVM: x86/mmu: Change KVM mmu shrinker to no-op

On 2024-09-13 02:43 PM, Vipin Sharma wrote:
> Remove global kvm_total_used_mmu_pages and page zapping flow from MMU
> shrinker. Keep shrinker infrastructure in place to reuse in future
> commits for freeing KVM page caches. Remove zapped_obsolete_pages list
> from struct kvm_arch{} and use local list in kvm_zap_obsolete_pages()
> since MMU shrinker is not using it anymore.
> 
> mmu_shrink_scan() is very disruptive to VMs. It picks the first VM in
> the vm_list, zaps the oldest page which is most likely an upper level
> SPTEs and most like to be reused. Prior to TDP MMU, this is even more
> disruptive in nested VMs case, considering L1 SPTEs will be the oldest
> even though most of the entries are for L2 SPTEs.
> 
> As discussed in
> https://lore.kernel.org/lkml/Y45dldZnI6OIf+a5@google.com/ shrinker logic
> has not be very useful in actually keeping VMs performant and reducing
> memory usage.
> 
> Suggested-by: Sean Christopherson <seanjc@...gle.com>
> Suggested-by: David Matlack <dmatlack@...gle.com>
> Signed-off-by: Vipin Sharma <vipinsh@...gle.com>
> ---

Reviewed-by: David Matlack <dmatlack@...gle.com>