Re: [PATCH 4/4] KVM: MMU: Make mmu_shrink() scan nr_to_scan shadow pages

[Avi Kivity <avi@redhat.com>]

On 12/19/2011 11:56 AM, Takuya Yoshikawa wrote:
> (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.

But is the shrinker really only called in emergencies?

Also, with things like cgroups, we may have an emergency in one
container, but not in others - if the shrinker is not cgroup aware, it
soon will be.

>
>>
>>>      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.

It wasn't, and in fact the original code was even worse, the code we
have now is after some fixes.

>
> 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?

Ok.

>
> 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.

We should aim for the following:
- normal operation causes very little shrinks (some are okay)
- high pressure mostly due to kvm results in kvm being shrunk (this is a
pathological case caused by a starting a guest with a huge amount of
memory, and mapping it all to /dev/zero (or ksm), and getting the guest
the create shadow mappings for all of it)
- general high pressure is shared among other caches like dcache and icache

The cost of reestablishing an mmu page can be as high as half a
millisecond of cpu time, which is the reason I want to be conservative.

-- 
error compiling committee.c: too many arguments to function