On Fri, 20 Apr 2012 19:15:24 -0700 Mike Waychison <mikew@xxxxxxxxxx> wrote: > In our situation, we simple disable the shrinker altogether. My > understanding is that we EPT or NPT, the amount of memory used by > these tables is bounded by the size of guest physical memory, whereas > with software shadowed tables, it is bounded by the addresses spaces > in the guest. This bound makes it reasonable to not do any reclaim > and charge it as a "system overhead tax". IIRC, KVM's mmu_shrink is mainly for protecting the host from pathological guest without EPT or NPT. You can see Avi's summary: -- http://www.spinics.net/lists/kvm/msg65671.html === 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. === Thanks, Takuya -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>