All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 0/2] KVM: x86/mmu: Repurpose MMU shrinker into page cache shrinker
@ 2024-09-13 21:43 Vipin Sharma
  2024-09-13 21:43 ` [PATCH 1/2] KVM: x86/mmu: Change KVM mmu shrinker to no-op Vipin Sharma
                   ` (2 more replies)
  0 siblings, 3 replies; 10+ messages in thread
From: Vipin Sharma @ 2024-09-13 21:43 UTC (permalink / raw)
  To: seanjc, pbonzini
  Cc: dmatlack, zhi.wang.linux, weijiang.yang, mizhang, liangchen.linux,
	kvm, linux-kernel, Vipin Sharma

This series is extracted out from the NUMA aware page table series[1].
MMU shrinker changes were in patches 1 to 9 in the old series.

This series is changing KVM MMU shrinker behaviour by emptying MMU page
caches which are used during page fault and MMU load operations. It also
incorporates feedback from the NUMA aware page table series[1] regarding
MMU shrinker.

KVM MMU shrinker has not been very effective in alleviating pain under
memory pressure. It frees up the pages actively being used which results
in VM degradation. VM will take fault and bring them again in page
tables. More discussions happened at [2]. Overall, consensus was to
reprupose it into the code which frees pages from KVM MMU page caches.

Recently [3], there was a discussion to disable shrinker for TDP MMU.
Revival of this series is result of that discussion.

There are two major differences from the old series.
1. There is no global accounting of cache pages. It is dynamically
   calculated in mmu_shrink_count(). This has two effects; i) counting will
   be inaccurate but code is much simpler, and ii) kvm_lock being used
   here, this should be fine as mmu_shrink_scan() also holds the lock
   for its operation.
2. Only empty mmu_shadow_page_cache and mmu_shadowed_info_cache. This
   version doesn't empty split_shadow_page_cache as it is used only
   during dirty logging operation and is one per VM unlike other two
   which are per vCPU. I am not fully convinced that adding it is needed
   as it will add the cost of adding one more mutex and synchronizing it
   in shrinker. Also, if a VM is being dirty tracked most likely it will
   be migrated (memory pressure might be the reason in the first place)
   so better to not hinder migration effort and let vCPUs free up their
   caches. If someone convinces me to add split cache as well then I can
   send a separate patch to add that as well.

[1] https://lore.kernel.org/kvm/20230306224127.1689967-1-vipinsh@google.com/
[2] https://lore.kernel.org/lkml/Y45dldZnI6OIf+a5@google.com/
[3] https://lore.kernel.org/kvm/20240819214014.GA2313467.vipinsh@google.com/#t


v1:
- No global counting of pages in cache. As this number might not remain
  same between calls of mmu_shrink_count() and mmu_shrink_scan().
- Count cache pages in mmu_shrink_count(). KVM can tolerate inaccuracy
  here.
- Empty mmu_shadow_page_cache and mmu_shadowed_info_cache only. Don't
  empty split_shadow_page_cache.

v0: Patches 1-9 from NUMA aware page table series.
https://lore.kernel.org/kvm/20230306224127.1689967-1-vipinsh@google.com/

Vipin Sharma (2):
  KVM: x86/mmu: Change KVM mmu shrinker to no-op
  KVM: x86/mmu: Use MMU shrinker to shrink KVM MMU memory caches

 arch/x86/include/asm/kvm_host.h |   7 +-
 arch/x86/kvm/mmu/mmu.c          | 139 +++++++++++++-------------------
 arch/x86/kvm/mmu/paging_tmpl.h  |  14 ++--
 include/linux/kvm_host.h        |   1 +
 virt/kvm/kvm_main.c             |   8 +-
 5 files changed, 78 insertions(+), 91 deletions(-)


base-commit: 12680d7b8ac4db2eba6237a21a93d2b0e78a52a6
-- 
2.46.0.662.g92d0881bb0-goog


^ permalink raw reply	[flat|nested] 10+ messages in thread
* Re: [PATCH 2/2] KVM: x86/mmu: Use MMU shrinker to shrink KVM MMU memory caches
@ 2024-09-15 20:34 kernel test robot
  0 siblings, 0 replies; 10+ messages in thread
From: kernel test robot @ 2024-09-15 20:34 UTC (permalink / raw)
  To: oe-kbuild; +Cc: lkp, Dan Carpenter

BCC: lkp@intel.com
CC: oe-kbuild-all@lists.linux.dev
In-Reply-To: <20240913214316.1945951-3-vipinsh@google.com>
References: <20240913214316.1945951-3-vipinsh@google.com>
TO: Vipin Sharma <vipinsh@google.com>
TO: seanjc@google.com
TO: pbonzini@redhat.com
CC: dmatlack@google.com
CC: zhi.wang.linux@gmail.com
CC: weijiang.yang@intel.com
CC: mizhang@google.com
CC: liangchen.linux@gmail.com
CC: kvm@vger.kernel.org
CC: linux-kernel@vger.kernel.org
CC: Vipin Sharma <vipinsh@google.com>

Hi Vipin,

kernel test robot noticed the following build warnings:

[auto build test WARNING on 12680d7b8ac4db2eba6237a21a93d2b0e78a52a6]

url:    https://github.com/intel-lab-lkp/linux/commits/Vipin-Sharma/KVM-x86-mmu-Change-KVM-mmu-shrinker-to-no-op/20240914-054449
base:   12680d7b8ac4db2eba6237a21a93d2b0e78a52a6
patch link:    https://lore.kernel.org/r/20240913214316.1945951-3-vipinsh%40google.com
patch subject: [PATCH 2/2] KVM: x86/mmu: Use MMU shrinker to shrink KVM MMU memory caches
:::::: branch date: 2 days ago
:::::: commit date: 2 days ago
config: x86_64-randconfig-r072-20240914 (https://download.01.org/0day-ci/archive/20240916/202409160405.myKhdFuN-lkp@intel.com/config)
compiler: clang version 18.1.8 (https://github.com/llvm/llvm-project 3b5b5c1ec4a3095ab096dd780e84d7ab81f3d7ff)

If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Reported-by: Dan Carpenter <error27@gmail.com>
| Closes: https://lore.kernel.org/r/202409160405.myKhdFuN-lkp@intel.com/

smatch warnings:
arch/x86/kvm/mmu/mmu.c:7023 mmu_shrink_scan() warn: iterator 'i' not incremented
arch/x86/kvm/mmu/mmu.c:7047 mmu_shrink_count() warn: iterator 'i' not incremented

vim +/i +7023 arch/x86/kvm/mmu/mmu.c

f8f559422b6c6a arch/x86/kvm/mmu.c     Xiao Guangrong      2013-06-07  7006  
f3d90f901d1874 arch/x86/kvm/mmu/mmu.c Sean Christopherson 2023-02-02  7007  static unsigned long mmu_shrink_scan(struct shrinker *shrink,
f3d90f901d1874 arch/x86/kvm/mmu/mmu.c Sean Christopherson 2023-02-02  7008  				     struct shrink_control *sc)
3ee16c814511cd arch/x86/kvm/mmu.c     Izik Eidus          2008-03-30  7009  {
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7010  	struct kvm *kvm, *next_kvm, *first_kvm = NULL;
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7011  	unsigned long i, freed = 0;
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7012  	struct kvm_vcpu *vcpu;
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7013  
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7014  	mutex_lock(&kvm_lock);
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7015  	list_for_each_entry_safe(kvm, next_kvm, &vm_list, vm_list) {
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7016  		if (!first_kvm)
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7017  			first_kvm = kvm;
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7018  		else if (first_kvm == kvm)
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7019  			break;
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7020  
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7021  		list_move_tail(&kvm->vm_list, &vm_list);
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7022  
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13 @7023  		kvm_for_each_vcpu(i, vcpu, kvm) {
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7024  			if (!mutex_trylock(&vcpu->arch.mmu_memory_cache_lock))
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7025  				continue;
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7026  			freed += kvm_mmu_empty_memory_cache(&vcpu->arch.mmu_shadow_page_cache);
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7027  			freed += kvm_mmu_empty_memory_cache(&vcpu->arch.mmu_shadowed_info_cache);
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7028  			mutex_unlock(&vcpu->arch.mmu_memory_cache_lock);
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7029  			if (freed >= sc->nr_to_scan)
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7030  				goto out;
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7031  		}
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7032  	}
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7033  out:
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7034  	mutex_unlock(&kvm_lock);
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7035  	return freed;
70534a739c12b9 arch/x86/kvm/mmu.c     Dave Chinner        2013-08-28  7036  }
70534a739c12b9 arch/x86/kvm/mmu.c     Dave Chinner        2013-08-28  7037  
f3d90f901d1874 arch/x86/kvm/mmu/mmu.c Sean Christopherson 2023-02-02  7038  static unsigned long mmu_shrink_count(struct shrinker *shrink,
f3d90f901d1874 arch/x86/kvm/mmu/mmu.c Sean Christopherson 2023-02-02  7039  				      struct shrink_control *sc)
70534a739c12b9 arch/x86/kvm/mmu.c     Dave Chinner        2013-08-28  7040  {
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7041  	unsigned long i, count = 0;
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7042  	struct kvm_vcpu *vcpu;
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7043  	struct kvm *kvm;
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7044  
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7045  	mutex_lock(&kvm_lock);
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7046  	list_for_each_entry(kvm, &vm_list, vm_list) {
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13 @7047  		kvm_for_each_vcpu(i, vcpu, kvm) {
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7048  			count += READ_ONCE(vcpu->arch.mmu_shadow_page_cache.nobjs);
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7049  			count += READ_ONCE(vcpu->arch.mmu_shadowed_info_cache.nobjs);
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7050  		}
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7051  	}
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7052  	mutex_unlock(&kvm_lock);
18e36705595ba3 arch/x86/kvm/mmu/mmu.c Vipin Sharma        2024-09-13  7053  	return !count ? SHRINK_EMPTY : count;
3ee16c814511cd arch/x86/kvm/mmu.c     Izik Eidus          2008-03-30  7054  }
3ee16c814511cd arch/x86/kvm/mmu.c     Izik Eidus          2008-03-30  7055  

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2024-10-02 16:17 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-09-13 21:43 [PATCH 0/2] KVM: x86/mmu: Repurpose MMU shrinker into page cache shrinker Vipin Sharma
2024-09-13 21:43 ` [PATCH 1/2] KVM: x86/mmu: Change KVM mmu shrinker to no-op Vipin Sharma
2024-09-25 23:54   ` David Matlack
2024-09-13 21:43 ` [PATCH 2/2] KVM: x86/mmu: Use MMU shrinker to shrink KVM MMU memory caches Vipin Sharma
2024-10-01 22:16   ` David Matlack
2024-10-02 16:17     ` Vipin Sharma
2024-09-25 23:51 ` [PATCH 0/2] KVM: x86/mmu: Repurpose MMU shrinker into page cache shrinker David Matlack
2024-09-30 16:42   ` Vipin Sharma
2024-09-30 16:50     ` David Matlack
  -- strict thread matches above, loose matches on Subject: below --
2024-09-15 20:34 [PATCH 2/2] KVM: x86/mmu: Use MMU shrinker to shrink KVM MMU memory caches kernel test robot

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.