qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: Christopher Pereira <kripper@imatronix.cl>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] Swap disks virtualization
Date: Mon, 13 Mar 2017 12:21:32 +0100	[thread overview]
Message-ID: <20170313112132.GB5545@noname.redhat.com> (raw)
In-Reply-To: <2e5a75c0-b142-5e23-4314-445385b2cdb6@imatronix.cl>

Am 13.03.2017 um 04:42 hat Christopher Pereira geschrieben:
> We are currently providing Linux swap disks with QEMU driver, virtio
> bus and qcow2 type.
> 
> Do you know any alternatives that provide better performance?
> 
> Considering that swap disks contain less critical data, QEMU could
> avoid disk IOs by using unassigned memory whenever possible. This
> could also be handled by the underlying linux filesystem of course.
> Can we tell QEMU to use the linux swap disk for creating a guest
> swap disk? What's the state of the art regarding swap disks
> virtualization?

I think the state of the art is to give the VMs enough memory rather
than making them use a swap disk. If the amount of memory required by
each VM changes dynamically, you can use memory ballooning or hotplug to
increase or decrease the memory size while the VM is running. If you
overcommit the memory, the VMs will automatically be part of the host's
swapping (with all performance implications of swapping, so I think
you'll still want to avoid it on the host, too).

But if you really, really want to use a swap disk in the VM for some
reason, there are three things that I would do:

1. Most importantly, set a good cache mode, cache=unsafe sounds
   perfectly fine here because you're not interested in the state of the
   image after a crash.

2. Consider putting the image on a tmpfs on the host. cache=unsafe will
   already make sure that qemu never forces Linux to write out the data
   in its cache with an fsync() call, but Linux will still do background
   writeouts. With tmpfs, that won't happen. Of course, the downside is
   that you're using actual host memory for it and rely on the host
   kernel to swap out the tmpfs rather than data of host processes,
   which may or may not work out. But I understand that this is more or
   less what you're asking for.

3. You're unlikely to use any interesting features with this image, so
   using raw instead of qcow2 could be possible. Don't expect too much
   here, especially if your qcow2 image is preallocated, but if you can
   use raw, it's always the best performing option.

Even with this, you still have the virtual disk I/O overhead for
accessing the VM's swap space, so it will never be as fast as just
giving the VM more memory.

Kevin

  reply	other threads:[~2017-03-13 11:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-13  3:42 [Qemu-devel] Swap disks virtualization Christopher Pereira
2017-03-13 11:21 ` Kevin Wolf [this message]
2017-03-13 14:51   ` Christopher Pereira

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=20170313112132.GB5545@noname.redhat.com \
    --to=kwolf@redhat.com \
    --cc=kripper@imatronix.cl \
    --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;
as well as URLs for NNTP newsgroup(s).