On Fri, Feb 24, 2012 at 6:41 AM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > On Thu, Feb 23, 2012 at 7:08 PM, peter.lie...@gmail.com <p...@dlh.net> wrote: >> >> >> >> >> Stefan Hajnoczi <stefa...@gmail.com> schrieb: >> >>>On Thu, Feb 23, 2012 at 3:40 PM, Peter Lieven <p...@dlh.net> 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
