qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Max Reitz <mreitz@redhat.com>
To: Stefan Hajnoczi <stefanha@gmail.com>
Cc: Kevin Wolf <kwolf@redhat.com>,
	qemu-devel@nongnu.org, Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH v5 0/8] Add metadata overlap checks
Date: Thu, 14 Nov 2013 19:37:54 +0100	[thread overview]
Message-ID: <52851882.3020707@redhat.com> (raw)
In-Reply-To: <20131105085115.GA13336@stefanha-thinkpad.redhat.com>

On 05.11.2013 09:51, Stefan Hajnoczi wrote:
> On Sat, Oct 26, 2013 at 03:03:09PM +0200, Max Reitz wrote:
>> 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).
> Good, looks like the impact isn't very noticable.
>
> I wonder if that 1.52% is reproducible or just noise, did you run the
> benchmark multiple times?
>
> Stefan

I just ran three tests for each (alternating between the modes), the
results are as following (comparing the total time):

overlap-check=none: 421.29 s, 412.37 s, 414.60 s
Average: 416.09 s
Standard deviation: 3.79 s

overlap-check=all: 420.02 s, 415.11 s, 423.37 s
Average: 419.50 s
Standard deviation: 3.39 s

So, using all overlap checks is nearly consistently slower – however,
the difference is exactly within the single standard deviation. There is
a difference, but first of all, it is pretty much unremarkable, and
second, remember all tests are run in tmpfs. This is the absolute
maximum slowdown we'll ever experience.

Max

  reply	other threads:[~2013-11-14 18:38 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
2013-10-26 13:05       ` Max Reitz
2013-11-05  8:51       ` Stefan Hajnoczi
2013-11-14 18:37         ` Max Reitz [this message]
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=52851882.3020707@redhat.com \
    --to=mreitz@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=stefanha@gmail.com \
    --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).