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

[Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>]

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

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

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

	Takuya