On Fri, 20 Apr 2012 19:15:24 -0700 Mike Waychison <[email protected]> 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 from this list: send the line "unsubscribe kvm" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
