Re: [PATCH] KVM: MMU: Fix mmu_shrink() so that it can free mmu pages as intended

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 5 Jul 2012 23:05:46 +0900
Takuya Yoshikawa <takuya.yoshikawa@xxxxxxxxx> wrote:

> On Thu, 5 Jul 2012 14:50:00 +0300
> Gleb Natapov <gleb@xxxxxxxxxx> wrote:
> 
> > > Note that "if (!nr_to_scan--)" check is removed since we do not try to
> > > free mmu pages from more than one VM.
> > > 
> > IIRC this was proposed in the past that we should iterate over vm list
> > until freeing something eventually, but Avi was against it. I think the
> > probability of a VM with kvm->arch.n_used_mmu_pages == 0 is low, so
> > it looks OK to drop nr_to_scan to me.
> 
> Since our batch size is 128, the minimum positive @nr_to_scan, it's almost
> impossible to see the effect of the check.

Thinking more about this:

I think freeing mmu pages by shrink_slab() is problematic.

For example, if we do
 # echo 2 /proc/sys/vm/drop_caches
on the host, some mmu pages will be freed.

This is not what most people expect, probably.


Although this patch is needed to care about shadow paging's extreme
mmu page usage, we should do somthing better in the future.

What I think reasonable is not treating all mmu pages as freeable:
 - determine some base number of mmu pages: base_mmu_pages
 - return (total_mmu_pages - base_mmu_pages) to the caller

 * We may use n_max_mmu_pages for calculating this base number.

By doing so, we can avoid freeing mmu pages especially when EPT/NPT ON.

Thanks,
	Takuya
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux