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/
next prev parent 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