Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: "Peter Lieven" <pl@dlh.net>
To: qemu-devel@nongnu.org
Cc: kvm@vger.kernel.org
Subject: linux guests and ksm performance
Date: Thu, 23 Feb 2012 16:40:44 +0100	[thread overview]
Message-ID: <1333613dbb15f2b736394d77e795223e.squirrel@ssl.dlh.net> (raw)

Hi,

i have recently been playing with an old idea (originally in grsecurity
for security reasons) to change
the policy from zero on allocate to zero after free in the linux page
allocator. My concern is that linux
leaves a lot of waste in the physical memory unlike Windows which per
default zeros pages after
they are freed.

I have run some tests and I can confirm some old results that a hardware
Linux machine
is approximately 2-3% slower with zero after free on big compilation jobs.
This might be due
to either the fact that pages are only zeroed on allocate if GFP_ZERO is
set or due to caching
benefits.

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.

Therefore I would like to hear your thoughts if it would be a good idea to
change
the strategy in the Linux kernel from zero on allocate to zero after free
automatically
if the 'hypervisor' cpu feature is set? Or even have another technique to
tell a linux
guest that ksm is running on the host.

If this is not feasible can someone think of a kernel module / userspace
program that
zeroes out unused pages periodically.

Peter



             reply	other threads:[~2012-02-23 15:40 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-23 15:40 Peter Lieven [this message]
2012-02-23 16:42 ` linux guests and ksm performance Stefan Hajnoczi
2012-02-23 18:39   ` Javier Guerra Giraldez
2012-02-23 19:08   ` peter.lieven@gmail.com
2012-02-24  6:41     ` Stefan Hajnoczi
2012-02-24  6:53       ` Stefan Hajnoczi
2012-02-24  7:23         ` Stefan Hajnoczi
2012-02-24  7:43           ` Peter Lieven
2012-02-28 11:46           ` [Qemu-devel] " Peter Lieven
2012-02-28 12:05             ` Stefan Hajnoczi
2012-02-28 12:16               ` Peter Lieven
2012-02-28 13:16       ` Avi Kivity
2012-02-28 13:20         ` Peter Lieven
2012-02-28 13:56           ` Avi Kivity
2012-02-24  7:04   ` Gleb Natapov
2012-02-28 13:14   ` Avi Kivity

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1333613dbb15f2b736394d77e795223e.squirrel@ssl.dlh.net \
    --to=pl@dlh.net \
    --cc=kvm@vger.kernel.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox