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