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

[Marcelo Tosatti <mtosatti@redhat.com>]

On Thu, Jul 12, 2012 at 06:35:09PM +0900, Takuya Yoshikawa wrote:
> On Thu, 5 Jul 2012 23:05:46 +0900
> Takuya Yoshikawa <takuya.yoshikawa@gmail.com> wrote:
> 
> > On Thu, 5 Jul 2012 14:50:00 +0300
> > Gleb Natapov <gleb@redhat.com> 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.

Takuya,

Can't understand, can you please expand more clearly? 

TIA