From: Marcelo Tosatti <mtosatti@redhat.com>
To: Takuya Yoshikawa <takuya.yoshikawa@gmail.com>
Cc: avi@redhat.com, kvm@vger.kernel.org, yoshikawa.takuya@oss.ntt.co.jp
Subject: Re: [PATCH 4/4] KVM: MMU: Make mmu_shrink() scan nr_to_scan shadow pages
Date: Fri, 16 Dec 2011 09:06:11 -0200 [thread overview]
Message-ID: <20111216110611.GC26982@amt.cnet> (raw)
In-Reply-To: <20111212072647.1990b19483b0a482a894a0f6@gmail.com>
On Mon, Dec 12, 2011 at 07:26:47AM +0900, Takuya Yoshikawa wrote:
> From: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
>
> Currently, mmu_shrink() tries to free a shadow page from one kvm and
> does not use nr_to_scan correctly.
>
> This patch fixes this by making it try to free some shadow pages from
> each kvm. The number of shadow pages each kvm frees becomes
> proportional to the number of shadow pages it is using.
>
> Note: an easy way to see how this code works is to do
> echo 3 > /proc/sys/vm/drop_caches
> during some virtual machines are running. Shadow pages will be zapped
> as expected by this.
I'm not sure this is a meaningful test to verify this change is
worthwhile, because while the shrinker tries to free a shadow page from
one vm, the vm's position in the kvm list is changed, so the over time
the shrinker will cycle over all VMs.
Can you measure whether there is a significant difference in a synthetic
workload, and what that change is? Perhaps apply {moderate, high} memory
pressure load with {2, 4, 8, 16} VMs or something like that.
next prev parent reply other threads:[~2011-12-16 11:42 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-11 22:22 [PATCH 0/4] KVM: Make mmu_shrink() scan nr_to_scan shadow pages Takuya Yoshikawa
2011-12-11 22:24 ` [PATCH 1/4] KVM: Rename vm_list to kvm_list to avoid confusion Takuya Yoshikawa
2011-12-12 3:16 ` Xiao Guangrong
2011-12-12 4:04 ` Takuya Yoshikawa
2011-12-12 4:51 ` Xiao Guangrong
2011-12-12 7:10 ` Takuya Yoshikawa
2011-12-11 22:24 ` [PATCH 2/4] KVM: MMU: Make common preparation code for zapping sp into a function Takuya Yoshikawa
2011-12-11 22:25 ` [PATCH 3/4] KVM: MMU: Make preparation for zapping some sp into a separate function Takuya Yoshikawa
2011-12-12 1:19 ` Takuya Yoshikawa
2011-12-11 22:26 ` [PATCH 4/4] KVM: MMU: Make mmu_shrink() scan nr_to_scan shadow pages Takuya Yoshikawa
2011-12-16 11:06 ` Marcelo Tosatti [this message]
2011-12-16 14:58 ` Takuya Yoshikawa
2011-12-19 8:43 ` Avi Kivity
2011-12-19 9:22 ` Takuya Yoshikawa
2011-12-19 9:26 ` Avi Kivity
2011-12-19 9:56 ` Takuya Yoshikawa
2011-12-19 10:03 ` Avi Kivity
2011-12-19 10:21 ` Takuya Yoshikawa
2011-12-19 10:24 ` 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=20111216110611.GC26982@amt.cnet \
--to=mtosatti@redhat.com \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=takuya.yoshikawa@gmail.com \
--cc=yoshikawa.takuya@oss.ntt.co.jp \
/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;
as well as URLs for NNTP newsgroup(s).