On Fri, Feb 24, 2012 at 6:41 AM, Stefan Hajnoczi <stefanha@xxxxxxxxx> wrote: > On Thu, Feb 23, 2012 at 7:08 PM, peter.lieven@xxxxxxxxx <pl@xxxxxxx> wrote: >> >> >> >> >> Stefan Hajnoczi <stefanha@xxxxxxxxx> schrieb: >> >>>On Thu, Feb 23, 2012 at 3:40 PM, Peter Lieven <pl@xxxxxxx> wrote: >>>> However, in a virtual machine I have not observed the above slow down >>>to >>>> that extend >>>> while the benefit of zero after free in a virtualisation environment >>>is >>>> obvious: >>>> >>>> 1) zero pages can easily be merged by ksm or other technique. >>>> 2) zero (dup) pages are a lot faster to transfer in case of >>>migration. >>> >>>The other approach is a memory page "discard" mechanism - which >>>obviously requires more code changes than zeroing freed pages. >>> >>>The advantage is that we don't take the brute-force and CPU intensive >>>approach of zeroing pages. It would be like a fine-grained ballooning >>>feature. >>> >> >> I dont think that it is cpu intense. All user pages are zeroed anyway, but at allocation time it shouldnt be a big difference in terms of cpu power. > > It's easy to find a scenario where eagerly zeroing pages is wasteful. > Imagine a process that uses all of physical memory. Once it > terminates the system is going to run processes that only use a small > set of pages. It's pointless zeroing all those pages if we're not > going to use them anymore. Perhaps the middle path is to zero pages but do it after a grace timeout. I wonder if this helps eliminate the 2-3% slowdown you noticed when compiling. This requires no special host<->guest interfaces for discarding pages. Stefan -- 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
