From: Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>
To: Avi Kivity <avi@redhat.com>
Cc: Takuya Yoshikawa <takuya.yoshikawa@gmail.com>,
Marcelo Tosatti <mtosatti@redhat.com>,
kvm@vger.kernel.org
Subject: Re: [PATCH 4/4] KVM: MMU: Make mmu_shrink() scan nr_to_scan shadow pages
Date: Mon, 19 Dec 2011 18:56:05 +0900 [thread overview]
Message-ID: <4EEF0A35.9010009@oss.ntt.co.jp> (raw)
In-Reply-To: <4EEF0354.4090603@redhat.com>
(2011/12/19 18:26), Avi Kivity wrote:
> On 12/19/2011 11:22 AM, Takuya Yoshikawa wrote:
>>> Yes, it's very conservative. But on the other hand the shrinker is
>>> tuned for dcache and icache, where there are usually tons of useless
>>> objects. If we have to free something, I'd rather free them instead of
>>> mmu pages which tend to get recreated soon.
>>>
>>
>>
>> OK, to satisfy the requirements, I will do:
>>
>> 1. find the guest with the highest (shadow pages / memory) ratio
>
> How do you propose to do that efficiently? We may have hundreds of
> guests, or even more, on one host. Each guest access will involve
> bouncing a few cache lines.
IMO, The goal should be restricted to emergencies.
So possible solution may be:
- we set the tuning parameters as conservative as possible
- pick up a guest with relatively high ratio
(I have to think more how to achieve this)
- move the vm_list head for fairness
In an emergency, we should not mind performance penalty so much.
>
>> 2. just zap one page from that guest, keeping the current
>> conservative rate
>>
>> I will update the patch.
>
> I think the current rate is too conservative. No idea what a good one
> is, I don't have a feeling as to the relation between shrinker callbacks
> and memory pressure.
>
When I tried to see what the current code is doing, frankly speaking,
I thought mmu_shrink() was not tested enough from the beginning.
I read the shrinker code as far as possible and realized the combination of
(seeks=10*default, batch=128) is not reasonable; the high seeks means the
shrinker rarely calculate higher value than 128, and mmu_shrink() cannot
be called in normal life.
How about setting the batch a bit lower, keeping seeks as is?
But there is not a perfect value because how often mmu_shrink() can be called
will change if the admin change the sysctl_vfs_cache_pressure tuning parameter
for dcache and icache, IIUC.
And tdp and shadow paging differ much.
Takuya
next prev parent reply other threads:[~2011-12-19 9:54 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
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 [this message]
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=4EEF0A35.9010009@oss.ntt.co.jp \
--to=yoshikawa.takuya@oss.ntt.co.jp \
--cc=avi@redhat.com \
--cc=kvm@vger.kernel.org \
--cc=mtosatti@redhat.com \
--cc=takuya.yoshikawa@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.