On Fri, Feb 24, 2012 at 6:53 AM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > 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.
Gah, it's too early in the morning. I don't think this timer actually makes sense. Stefan
