From: "Pavel Dovgalyuk" <dovgaluk@ispras.ru>
To: 'Kevin Wolf' <kwolf@redhat.com>
Cc: 'Pavel Dovgalyuk' <Pavel.Dovgaluk@ispras.ru>,
qemu-devel@nongnu.org, peter.maydell@linaro.org,
war2jordan@live.com, crosthwaite.peter@gmail.com,
boost.lists@gmail.com, artem.k.pisarenko@gmail.com,
quintela@redhat.com, ciro.santilli@gmail.com,
jasowang@redhat.com, mst@redhat.com, armbru@redhat.com,
mreitz@redhat.com, maria.klimushenkova@ispras.ru,
kraxel@redhat.com, thomas.dullien@googlemail.com,
pbonzini@redhat.com, alex.bennee@linaro.org, dgilbert@redhat.com,
rth@twiddle.net
Subject: Re: [Qemu-devel] [PATCH v13 19/25] replay: add BH oneshot event for block layer
Date: Wed, 6 Mar 2019 17:00:44 +0300 [thread overview]
Message-ID: <001901d4d424$fe2a1930$fa7e4b90$@ru> (raw)
In-Reply-To: <20190306103324.GD6818@localhost.localdomain>
> From: Kevin Wolf [mailto:kwolf@redhat.com]
> Am 06.03.2019 um 10:37 hat Pavel Dovgalyuk geschrieben:
> > > From: Kevin Wolf [mailto:kwolf@redhat.com]
> > > Am 06.03.2019 um 10:18 hat Pavel Dovgalyuk geschrieben:
> > > > > Something like:
> > > > >
> > > > > -drive file=null-co://,if=none,id=null -device virtio-blk,drive=null
> > > >
> > > > And this drive should be destination of the copy operations, right?
> > >
> > > I don't know your exact benchmark, but this drive should be where the
> > > high I/O rates are, yes.
> >
> > Ok.
> >
> > > For getting meaningful numbers, you should have I/O only on the fast
> > > test disk (you're talking about a copy, where is source?),
> >
> > We used a qcow2 image as a source.
>
> So the source is going to slow down the I/O and you won't actually test
> whether the possible maximum changes.
>
> > > you should
> > > use direct I/O to get the page cache of the guest out of the way, and
> > > you should make sure that multiple requests are issued in parallel.
> >
> > Is this possible, if we have only conventional HDDs?
>
> null-co:// doesn't access your disk at all, so if this is the only
> virtual disk that has I/O, the conventional HDD doesn't hurt. But you're
> right that you probably can't use your physical disk for high
> performance benchmarks then.
>
> I'm going to suggest once more to use fio for storage testing. Actually,
> maybe I can find the time to do this myself on my system, too.
We've made some testing with the following fio configs:
[readtest]
blocksize=4k
filename=/dev/vda
rw=randread
direct=1
buffered=0
ioengine=libaio
iodepth=32
[writetest]
blocksize=4k
filename=/dev/vda
rw=randwrite
direct=1
buffered=0
ioengine=libaio
iodepth=32
One with read, one with write, and one with both.
master branch:
1 read : io=1024.0MB, bw=475545KB/s, iops=118886, runt= 2205msec
2 write: io=1024.0MB, bw=445444KB/s, iops=111361, runt= 2354msec
3 read : io=1024.0MB, bw=229850KB/s, iops=57462, runt= 4562msec
write: io=1024.0MB, bw=227210KB/s, iops=56802, runt= 4615msec
rr branch:
1 read : io=1024.0MB, bw=479021KB/s, iops=119755, runt= 2189msec
2 write: io=1024.0MB, bw=440763KB/s, iops=110190, runt= 2379msec
3 read : io=1024.0MB, bw=230456KB/s, iops=57614, runt= 4550msec
write: io=1024.0MB, bw=228548KB/s, iops=57136, runt= 4588msec
It seems that the difference can't be measured in our environment.
Pavel Dovgalyuk
next prev parent reply other threads:[~2019-03-06 14:00 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-21 11:04 [Qemu-devel] [PATCH v13 00/25] Fixing record/replay and adding reverse debugging Pavel Dovgalyuk
2019-02-21 11:04 ` [Qemu-devel] [PATCH v13 01/25] replay: add missing fix for internal function Pavel Dovgalyuk
2019-02-21 11:04 ` [Qemu-devel] [PATCH v13 02/25] block: implement bdrv_snapshot_goto for blkreplay Pavel Dovgalyuk
2019-02-21 11:04 ` [Qemu-devel] [PATCH v13 03/25] replay: disable default snapshot for record/replay Pavel Dovgalyuk
2019-02-21 11:04 ` [Qemu-devel] [PATCH v13 04/25] replay: update docs for record/replay with block devices Pavel Dovgalyuk
2019-02-21 11:04 ` [Qemu-devel] [PATCH v13 05/25] replay: don't drain/flush bdrv queue while RR is working Pavel Dovgalyuk
2019-02-21 11:04 ` [Qemu-devel] [PATCH v13 06/25] replay: finish record/replay before closing the disks Pavel Dovgalyuk
2019-02-21 11:04 ` [Qemu-devel] [PATCH v13 07/25] qcow2: introduce icount field for snapshots Pavel Dovgalyuk
2019-02-21 11:04 ` [Qemu-devel] [PATCH v13 08/25] migration: " Pavel Dovgalyuk
2019-02-21 11:04 ` [Qemu-devel] [PATCH v13 09/25] replay: provide an accessor for rr filename Pavel Dovgalyuk
2019-02-21 11:05 ` [Qemu-devel] [PATCH v13 10/25] qapi: introduce replay.json for record/replay-related stuff Pavel Dovgalyuk
2019-02-21 11:05 ` [Qemu-devel] [PATCH v13 11/25] replay: introduce info hmp/qmp command Pavel Dovgalyuk
2019-02-21 11:05 ` [Qemu-devel] [PATCH v13 12/25] replay: introduce breakpoint at the specified step Pavel Dovgalyuk
2019-02-21 11:05 ` [Qemu-devel] [PATCH v13 13/25] replay: implement replay-seek command Pavel Dovgalyuk
2019-02-21 11:05 ` [Qemu-devel] [PATCH v13 14/25] replay: refine replay-time module Pavel Dovgalyuk
2019-02-21 11:05 ` [Qemu-devel] [PATCH v13 15/25] replay: flush rr queue before loading the vmstate Pavel Dovgalyuk
2019-02-21 11:05 ` [Qemu-devel] [PATCH v13 16/25] gdbstub: add reverse step support in replay mode Pavel Dovgalyuk
2019-02-21 11:05 ` [Qemu-devel] [PATCH v13 17/25] gdbstub: add reverse continue " Pavel Dovgalyuk
2019-02-21 11:05 ` [Qemu-devel] [PATCH v13 18/25] replay: describe reverse debugging in docs/replay.txt Pavel Dovgalyuk
2019-02-21 11:05 ` [Qemu-devel] [PATCH v13 19/25] replay: add BH oneshot event for block layer Pavel Dovgalyuk
2019-03-04 10:33 ` Kevin Wolf
2019-03-04 12:17 ` Pavel Dovgalyuk
2019-03-05 9:52 ` Kevin Wolf
2019-03-05 11:04 ` Pavel Dovgalyuk
2019-03-05 11:12 ` Kevin Wolf
2019-03-06 8:33 ` Pavel Dovgalyuk
2019-03-06 9:09 ` Kevin Wolf
2019-03-06 9:18 ` Pavel Dovgalyuk
2019-03-06 9:29 ` Kevin Wolf
2019-03-06 9:37 ` Pavel Dovgalyuk
2019-03-06 10:33 ` Kevin Wolf
2019-03-06 10:57 ` Pavel Dovgalyuk
2019-03-06 14:00 ` Pavel Dovgalyuk [this message]
2019-02-21 11:05 ` [Qemu-devel] [PATCH v13 20/25] replay: init rtc after enabling the replay Pavel Dovgalyuk
2019-02-21 11:06 ` [Qemu-devel] [PATCH v13 21/25] replay: document development rules Pavel Dovgalyuk
2019-02-21 11:06 ` [Qemu-devel] [PATCH v13 22/25] util/qemu-timer: refactor deadline calculation for external timers Pavel Dovgalyuk
2019-02-21 11:06 ` [Qemu-devel] [PATCH v13 23/25] replay: fix replay shutdown Pavel Dovgalyuk
2019-02-21 11:06 ` [Qemu-devel] [PATCH v13 24/25] replay: rename step-related variables and functions Pavel Dovgalyuk
2019-02-21 11:06 ` [Qemu-devel] [PATCH v13 25/25] icount: clean up cpu_can_io before jumping to the next block Pavel Dovgalyuk
2019-03-04 7:46 ` [Qemu-devel] [PATCH v13 00/25] Fixing record/replay and adding reverse debugging Pavel Dovgalyuk
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='001901d4d424$fe2a1930$fa7e4b90$@ru' \
--to=dovgaluk@ispras.ru \
--cc=Pavel.Dovgaluk@ispras.ru \
--cc=alex.bennee@linaro.org \
--cc=armbru@redhat.com \
--cc=artem.k.pisarenko@gmail.com \
--cc=boost.lists@gmail.com \
--cc=ciro.santilli@gmail.com \
--cc=crosthwaite.peter@gmail.com \
--cc=dgilbert@redhat.com \
--cc=jasowang@redhat.com \
--cc=kraxel@redhat.com \
--cc=kwolf@redhat.com \
--cc=maria.klimushenkova@ispras.ru \
--cc=mreitz@redhat.com \
--cc=mst@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=rth@twiddle.net \
--cc=thomas.dullien@googlemail.com \
--cc=war2jordan@live.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).