On 24.02.2012 08:23, Stefan Hajnoczi wrote:
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.
do you think it makes then sense to make a patchset/proposal to notice a
guest
kernel about the presense of ksm in the host and switch to zero after free?
peter
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
