From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: qemu-block@nongnu.org
Cc: kwolf@redhat.com, vsementsov@virtuozzo.com, ehabkost@redhat.com,
wencongyang2@huawei.com, xiechanglong.d@gmail.com,
armbru@redhat.com, qemu-devel@nongnu.org, jsnow@redhat.com,
crosa@redhat.com, den@openvz.org, mreitz@redhat.com
Subject: [RFC 00/24] backup performance: block_status + async
Date: Fri, 15 Nov 2019 17:14:20 +0300 [thread overview]
Message-ID: <20191115141444.24155-1-vsementsov@virtuozzo.com> (raw)
Hi all!
These series does the following things:
1. bring block_status to block-copy, for efficient chunk sizes and
handling ZERO clusters. (mirror does it)
2. bring aio-task-pool to block-copy, for parallel copying loop
iteration. (mirror does it its own way)
4. add speed limit and cancelling possibility to block-copy (for 5.)
5. use block-copy in backup directly, to bring block_status and async.
tasks into backup
6. add some python scripts to benchmark the results
The main theme is async handling of copying loop iterations, which
already works and bring performance in mirror (in its own way) and in
qcow2 (using aio-task-pool).
Here are the results:
---------- ------------- ----------------- ------------- ----------------- -------------
backup-old backup-old(no CR) backup-new backup-new(no CR) mirror
ssd -> ssd 9.88 +- 0.85 8.85 +- 0.48 5.39 +- 0.04 4.06 +- 0.01 4.15 +- 0.03
ssd -> hdd 10.90 +- 0.30 10.39 +- 0.41 9.36 +- 0.06 9.24 +- 0.06 9.00 +- 0.06
hdd -> hdd 20.09 +- 0.23 20.15 +- 0.07 48.65 +- 1.86 20.62 +- 0.08 19.82 +- 0.37
---------- ------------- ----------------- ------------- ----------------- -------------
---------- ------------- ------------- -------------
backup-old backup-new mirror
nbd -> ssd 30.69 +- 0.23 9.02 +- 0.00 9.06 +- 0.03
ssd -> nbd 36.94 +- 0.01 11.50 +- 0.08 10.12 +- 0.05
---------- ------------- ------------- -------------
Here:
"old" means "before series"
"new" means "after series"
"no CR" means "copy_range disabled"
nbd is nbd server on another node, running like
"qemu-nbd --persistent --nocache -p 10810 ones1000M-source"
RFC.1
What I noticed, is that copy_range makes things worse.. Is there any
case or benchmarking which shows that copy_range increases performance?
Possibly we should disable it by default..
RFC.2
Last patch isn't for commit, possibly I should make some generic
example, ideas are welcome
RFC.3
The series are big and splittable. The reason to send it alltogether is
that I wanted to get the whole picture to benchmark.
Also, I keep in mind benchmarking backup to qcow2 with different levels
of defragmentation and with/without compression.
Future plan is obvious: move block-commit and block-stream to use
block-copy, which will unify code path and bring performance to commit
and stream.
Vladimir Sementsov-Ogievskiy (24):
block/block-copy: specialcase first copy_range request
block/block-copy: use block_status
block/block-copy: factor out block_copy_find_inflight_req
block/block-copy: refactor interfaces to use bytes instead of end
block/block-copy: rename start to offset in interfaces
block/block-copy: reduce intersecting request lock
block/block-copy: hide structure definitions
block/block-copy: rename in-flight requests to tasks
block/block-copy: alloc task on each iteration
block/block-copy: add state pointer to BlockCopyTask
block/block-copy: move task size initial calculation to _task_create
block/block-copy: move block_copy_task_create down
block/block-copy: use aio-task-pool API
block/block-copy: More explicit call_state
block/block-copy: implement block_copy_async
block/block-copy: add max_chunk and max_workers paramters
block/block-copy: add ratelimit to block-copy
block/block-copy: add block_copy_cancel
blockjob: add set_speed to BlockJobDriver
job: call job_enter from job_user_pause
backup: move to block-copy
python: add simplebench.py
python: add qemu/bench_block_job.py
python: benchmark new backup architecture
qapi/block-core.json | 9 +-
include/block/block-copy.h | 90 ++---
include/block/block_int.h | 7 +
include/block/blockjob_int.h | 2 +
block/backup-top.c | 6 +-
block/backup.c | 184 ++++++----
block/block-copy.c | 608 ++++++++++++++++++++++++++++-----
block/replication.c | 1 +
blockdev.c | 5 +
blockjob.c | 6 +
job.c | 1 +
block/trace-events | 1 +
python/bench-example.py | 93 +++++
python/qemu/bench_block_job.py | 114 +++++++
python/simplebench.py | 122 +++++++
tests/qemu-iotests/129 | 3 +-
tests/qemu-iotests/185 | 3 +-
tests/qemu-iotests/219 | 1 +
tests/qemu-iotests/257 | 1 +
tests/qemu-iotests/257.out | 306 ++++++++---------
20 files changed, 1184 insertions(+), 379 deletions(-)
create mode 100755 python/bench-example.py
create mode 100755 python/qemu/bench_block_job.py
create mode 100644 python/simplebench.py
--
2.21.0
next reply other threads:[~2019-11-15 14:21 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-11-15 14:14 Vladimir Sementsov-Ogievskiy [this message]
2019-11-15 14:14 ` [RFC 01/24] block/block-copy: specialcase first copy_range request Vladimir Sementsov-Ogievskiy
2019-11-15 14:14 ` [RFC 02/24] block/block-copy: use block_status Vladimir Sementsov-Ogievskiy
2019-11-15 14:14 ` [RFC 03/24] block/block-copy: factor out block_copy_find_inflight_req Vladimir Sementsov-Ogievskiy
2019-11-15 14:14 ` [RFC 04/24] block/block-copy: refactor interfaces to use bytes instead of end Vladimir Sementsov-Ogievskiy
2019-11-15 14:14 ` [RFC 05/24] block/block-copy: rename start to offset in interfaces Vladimir Sementsov-Ogievskiy
2019-11-15 14:14 ` [RFC 06/24] block/block-copy: reduce intersecting request lock Vladimir Sementsov-Ogievskiy
2019-11-15 14:14 ` [RFC 07/24] block/block-copy: hide structure definitions Vladimir Sementsov-Ogievskiy
2019-11-15 14:14 ` [RFC 08/24] block/block-copy: rename in-flight requests to tasks Vladimir Sementsov-Ogievskiy
2019-11-15 14:14 ` [RFC 09/24] block/block-copy: alloc task on each iteration Vladimir Sementsov-Ogievskiy
2019-11-15 14:14 ` [RFC 10/24] block/block-copy: add state pointer to BlockCopyTask Vladimir Sementsov-Ogievskiy
2019-11-15 14:14 ` [RFC 11/24] block/block-copy: move task size initial calculation to _task_create Vladimir Sementsov-Ogievskiy
2019-11-15 14:14 ` [RFC 12/24] block/block-copy: move block_copy_task_create down Vladimir Sementsov-Ogievskiy
2019-11-15 14:14 ` [RFC 13/24] block/block-copy: use aio-task-pool API Vladimir Sementsov-Ogievskiy
2019-11-15 14:14 ` [RFC 14/24] block/block-copy: More explicit call_state Vladimir Sementsov-Ogievskiy
2019-11-15 14:14 ` [RFC 15/24] block/block-copy: implement block_copy_async Vladimir Sementsov-Ogievskiy
2019-11-15 14:14 ` [RFC 16/24] block/block-copy: add max_chunk and max_workers paramters Vladimir Sementsov-Ogievskiy
2019-11-15 14:14 ` [RFC 17/24] block/block-copy: add ratelimit to block-copy Vladimir Sementsov-Ogievskiy
2019-11-15 14:14 ` [RFC 18/24] block/block-copy: add block_copy_cancel Vladimir Sementsov-Ogievskiy
2019-11-15 14:14 ` [RFC 19/24] blockjob: add set_speed to BlockJobDriver Vladimir Sementsov-Ogievskiy
2019-11-15 14:14 ` [RFC 20/24] job: call job_enter from job_user_pause Vladimir Sementsov-Ogievskiy
2019-11-15 14:14 ` [RFC 21/24] backup: move to block-copy Vladimir Sementsov-Ogievskiy
2019-11-15 17:58 ` Eric Blake
2019-11-16 9:28 ` Vladimir Sementsov-Ogievskiy
2019-11-15 14:14 ` [RFC 22/24] python: add simplebench.py Vladimir Sementsov-Ogievskiy
2019-11-15 14:14 ` [RFC 23/24] python: add qemu/bench_block_job.py Vladimir Sementsov-Ogievskiy
2019-11-15 14:14 ` [RFC 24/24] python: benchmark new backup architecture Vladimir Sementsov-Ogievskiy
2019-11-15 17:30 ` [RFC 00/24] backup performance: block_status + async no-reply
2019-11-15 17:33 ` Vladimir Sementsov-Ogievskiy
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=20191115141444.24155-1-vsementsov@virtuozzo.com \
--to=vsementsov@virtuozzo.com \
--cc=armbru@redhat.com \
--cc=crosa@redhat.com \
--cc=den@openvz.org \
--cc=ehabkost@redhat.com \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=wencongyang2@huawei.com \
--cc=xiechanglong.d@gmail.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).