From: Kevin Wolf <kwolf@redhat.com>
To: Gleb Stepanov <gstepanov@mirantis.com>
Cc: qemu-devel@nongnu.org, qemu-discuss@nongnu.org
Subject: Re: [Qemu-devel] write operations during read
Date: Thu, 16 Jul 2015 12:00:44 +0200 [thread overview]
Message-ID: <20150716100044.GB5050@noname.redhat.com> (raw)
In-Reply-To: <CAKk_wU6zCN8d7biKXhOzmaCcOienX48Lq_9LFWnhgvxiaQaHsg@mail.gmail.com>
Hi Gleb,
Am 15.07.2015 um 13:04 hat Gleb Stepanov geschrieben:
> We are testing disk I/O perfomance using fio tool. I've measured
> performance on qcow2 image mounted to nb0 device. I run tests and
> launch iostat -x 1 command to browse I/O operations. Test consists of
> sequential read operations with 1 MB size. I've get following output.
>
> Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s
> sda 0.00 5.00 0.00 677.00 0.00 22812.00
> sdb 0.00 0.00 0.00 545.00 0.00 0.00
> dm-0 0.00 0.00 0.00 674.00 0.00 22784.00
> dm-1 0.00 0.00 0.00 7.00 0.00 28.00
> dm-2 0.00 0.00 0.00 0.00 0.00 0.00
> nb0 0.00 0.00 432.00 182.00 55296.00 23296.00
>
> So, reading produce a lot of write operations. What is the reason why
> these write operations occured?
Unfortunately you didn't include your qemu command line and didn't
describe in detail what your test setup looked like, so I'll have to
take a guess.
Read requests never cause writes. However, you wrote 55 MB to the image
before running the test. Did you make sure that this data was already
flushed to the disk before starting your benchmark? If it was only
sitting in the kernel page cache, the kernel can decide to write it out
at any point.
> How to determina block size that qemu operates , because if i've
> writtien 55 mb with 1 mb blocks
> i should get 55 operations instead of 432.
If you didn't use O_DIRECT in the benchmark, chances are that the guest
kernel issues requests smaller than 1 MB to qemu.
Be aware that you might get a few metadata reads in the guest
filesystem, the qcow2 and the host filesystem layer, so slightly more
than 55 requests is expected. Each layer may also have to split requests
if the data is stored fragmented.
Also, did you make sure that no processes other than fio access the
disk?
Kevin
next prev parent reply other threads:[~2015-07-16 10:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-15 11:04 [Qemu-devel] write operations during read Gleb Stepanov
2015-07-16 10:00 ` Kevin Wolf [this message]
2015-07-16 13:37 ` 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=20150716100044.GB5050@noname.redhat.com \
--to=kwolf@redhat.com \
--cc=gstepanov@mirantis.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-discuss@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).