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

[Avi Kivity <avi@redhat.com>]

On 12/19/2011 12:21 PM, Takuya Yoshikawa wrote:
> (2011/12/19 19:03), Avi Kivity wrote:
>>> 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?
>
> No, sadly.
>
> That is the problem.

It's not a problem - otherwise the icache and dcache would grow
indefinitely.

kvm's caches have another limit - perhaps we should remove it and let
the shrinker manage the caches itself (but that requires a better
selection algorithm).

>
>>
>> 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.
>
> That seems to be a common problem for everyone, not KVM only.

It's really a requirement for dcache/icache, otherwise one container
could force out icache/dcache for another.  It doesn't concern us
directly but we have to ensure that one guest cannot force out another's
mmu pages.

>
>>> 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.
>>
>
> I agree with you.
>
> I feel that I should add lkml in CC next time to hear from mm specialist.
> Shrinker has many heuristics added from a lot of experience; my lack of
> such experience means I need help.

Copying one expert.

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