public inbox for kvm@vger.kernel.org
 help / color / mirror / Atom feed
From: Anthony Liguori <anthony@codemonkey.ws>
To: Izik Eidus <izike@qumranet.com>
Cc: kvm-devel <kvm-devel@lists.sourceforge.net>
Subject: Re: [PATCH] shrinker support for the mmu cache
Date: Wed, 12 Mar 2008 14:45:31 -0500	[thread overview]
Message-ID: <47D832DB.9020209@codemonkey.ws> (raw)
In-Reply-To: <1205345621.16712.4.camel@localhost.localdomain>

Izik Eidus wrote:
> this patch simply register the mmu cache with the shrinker.

Please inline patches in the future as it makes it easier to review.  
The implementation looks good and I think it's a good idea.

One is that there is one shrinker for all VMs but you run through the 
list of VMs in order.  This means the first VM in the list is most 
frequently going to be shrunk down to KVM_MIN_ALLOC_MMU_PAGES.  This 
seems unfair and potentially dangerous.  The shrinker can be triggered 
potentially by the growth of the MMU cache on other VMs.

I think in the least, you should attempt to go through the VMs in a 
round-robin fashion to ensure that if you shrink one VM, the next time 
you'll shrink a different VM.

The other thing I wonder about is whether DEFAULT_SEEKS is the best 
value to use.  On the one hand, a guest page fault is probably not as 
expensive as reclaiming something from disk.  On the other hand, NPT 
guests are likely to be very sensitive to evicting things from the 
shadow page cache.  I would think it's pretty clear that in the NPT 
case, the MMU cache should have a higher seek cost than the default.

Regards,

Anthony Liguori

> ------------------------------------------------------------------------
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> ------------------------------------------------------------------------
>
> _______________________________________________
> kvm-devel mailing list
> kvm-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/kvm-devel
>   


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

  reply	other threads:[~2008-03-12 19:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-12 18:13 [PATCH] shrinker support for the mmu cache Izik Eidus
2008-03-12 19:45 ` Anthony Liguori [this message]
2008-03-12 23:32   ` Izik Eidus
2008-03-12 22:59 ` Marcelo Tosatti
2008-03-12 23:23   ` Izik Eidus
2008-03-13 21:55     ` Marcelo Tosatti
2008-03-16 11:28   ` Avi Kivity
2008-03-17 13:53     ` Marcelo Tosatti
2008-03-17 14:41       ` Avi Kivity
2008-03-17 21:33         ` Marcelo Tosatti
2008-03-18  6:29           ` Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=47D832DB.9020209@codemonkey.ws \
    --to=anthony@codemonkey.ws \
    --cc=izike@qumranet.com \
    --cc=kvm-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox