qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Stefan Hajnoczi <stefanha@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH v5 0/8] Add metadata overlap checks
Date: Sat, 26 Oct 2013 15:03:09 +0200	[thread overview]
Message-ID: <526BBD8D.7010301@redhat.com> (raw)
In-Reply-To: <20130920103202.GA14159@stefanha-thinkpad.redhat.com>

Am 20.09.2013 12:32, schrieb Stefan Hajnoczi:
> On Thu, Sep 19, 2013 at 05:07:56PM +0200, Max Reitz wrote:
>> As far as I understand, the I/O speed (the duration of an I/O
>> operation) should be pretty much the same for all scenarios,
>> however, the latency is the value in question (since the overlap
>> checks should affect the latency only).
> The other value to look at is the host CPU consumption per I/O.  In
> other words, the CPU overhead added by performing the extra checks:
>
>   efficiency = avg throughput / avg cpu utilization
>
> Once CPU consumption reaches 100% the workload is CPU-bound and we have
> a bottleneck.
>
> Hopefully the efficiency doesn't change noticably either, then we know
> there is no big impact from the extra checks.
>
> Stefan

Okay, after fixing the VM state in qcow2, I was now finally able to
actually perform the CPU benchmark. On second thought, it wasn't really
neccessary, since I performed most of the tests in RAM anyway, so the
CPU was already the bottleneck for these tests.

I ran bonnie++ (bonnie++ -s 4g -n 0 -x 16) from an arch live CD ISO on a
5 GB qcow2 image formatted as ext4, both residing in /tmp; I prepared
the VM state to the point where I just had to press Enter to perform the
test and shut down the VM. I then performed a snapshot and used this
image as the basis for two tests, one with no overlap checks enabled and
one with all of them enabled.

The time output for both qemu instances was respectively:

echo 'sendkey ret' | time $QEMU_DIR/x86_64-softmmu/qemu-system-x86_64
-cdrom arch.iso -drive file=base.qcow2,overlap-check=none -enable-kvm
-vga std -m 512 -loadvm 0 -monitor stdio
d  294.42s user 117.72s system 98% cpu 6:58.00 total

echo 'sendkey ret' | time $QEMU_DIR/x86_64-softmmu/qemu-system-x86_64
-cdrom arch.iso -drive file=base.qcow2,overlap-check=all -enable-kvm
-vga std -m 512 -loadvm 0 -monitor stdio
d  298.87s user 119.55s system 100% cpu 6:56.37 total

So, as you can see, the CPU time differs only marginally (using all
overlap checks instead of none took 1.52 % more CPU time).

Max

  reply	other threads:[~2013-10-26 13:03 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-02  7:25 [Qemu-devel] [PATCH v5 0/8] Add metadata overlap checks Max Reitz
2013-09-02  7:25 ` [Qemu-devel] [PATCH v5 1/8] qcow2: Add corrupt bit Max Reitz
2013-09-02  7:25 ` [Qemu-devel] [PATCH v5 2/8] qcow2: Metadata overlap checks Max Reitz
2013-09-02  7:25 ` [Qemu-devel] [PATCH v5 3/8] qcow2: Employ metadata " Max Reitz
2013-09-02  7:25 ` [Qemu-devel] [PATCH v5 4/8] qcow2-refcount: Move OFLAG_COPIED checks Max Reitz
2013-09-02  7:25 ` [Qemu-devel] [PATCH v5 5/8] qcow2-refcount: Repair OFLAG_COPIED errors Max Reitz
2013-09-02  7:25 ` [Qemu-devel] [PATCH v5 6/8] qcow2-refcount: Repair shared refcount blocks Max Reitz
2013-09-02  7:25 ` [Qemu-devel] [PATCH v5 7/8] qcow2_check: Mark image consistent Max Reitz
2013-09-02  7:25 ` [Qemu-devel] [PATCH v5 8/8] qemu-iotests: Overlapping cluster allocations Max Reitz
2013-09-12 14:57 ` [Qemu-devel] [PATCH v5 0/8] Add metadata overlap checks Eric Blake
2013-09-12 15:24   ` Max Reitz
2013-09-13  9:57     ` Kevin Wolf
2013-09-13 10:23       ` Max Reitz
2013-09-13 12:29         ` Eric Blake
2013-09-13 12:37           ` Max Reitz
2013-09-13 14:29           ` Max Reitz
2013-09-13 14:34             ` Eric Blake
2013-09-19 15:07 ` Max Reitz
2013-09-19 17:26   ` Eric Blake
2013-09-20  8:23     ` Max Reitz
2013-09-20 10:32   ` Stefan Hajnoczi
2013-10-26 13:03     ` Max Reitz [this message]
2013-10-26 13:05       ` Max Reitz
2013-11-05  8:51       ` Stefan Hajnoczi
2013-11-14 18:37         ` Max Reitz
2013-11-15  8:13           ` Stefan Hajnoczi

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=526BBD8D.7010301@redhat.com \
    --to=mreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@redhat.com \
    /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).