(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
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
