From: Max Reitz <mreitz@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org
Cc: kwolf@redhat.com, den@openvz.org
Subject: Re: [Qemu-devel] [PATCH 0/7] qcow2: async handling of fragmented io
Date: Thu, 16 Aug 2018 02:51:35 +0200 [thread overview]
Message-ID: <13910182-771b-c5dc-26a7-0958a7241fe8@redhat.com> (raw)
In-Reply-To: <20180807174311.32454-1-vsementsov@virtuozzo.com>
[-- Attachment #1: Type: text/plain, Size: 1882 bytes --]
On 2018-08-07 19:43, Vladimir Sementsov-Ogievskiy wrote:
> Hi all!
>
> Here is an asynchronous scheme for handling fragmented qcow2
> reads and writes. Both qcow2 read and write functions loops through
> sequential portions of data. The series aim it to parallelize these
> loops iterations.
>
> It improves performance for fragmented qcow2 images, I've tested it
> as follows:
>
> I have four 4G qcow2 images (with default 64k block size) on my ssd disk:
> t-seq.qcow2 - sequentially written qcow2 image
> t-reverse.qcow2 - filled by writing 64k portions from end to the start
> t-rand.qcow2 - filled by writing 64k portions (aligned) in random order
> t-part-rand.qcow2 - filled by shuffling order of 64k writes in 1m clusters
> (see source code of image generation in the end for details)
>
> and the test (sequential io by 1mb chunks):
>
> test write:
> for t in /ssd/t-*; \
> do sync; echo 1 > /proc/sys/vm/drop_caches; echo === $t ===; \
> ./qemu-img bench -c 4096 -d 1 -f qcow2 -n -s 1m -t none -w $t; \
> done
>
> test read (same, just drop -w parameter):
> for t in /ssd/t-*; \
> do sync; echo 1 > /proc/sys/vm/drop_caches; echo === $t ===; \
> ./qemu-img bench -c 4096 -d 1 -f qcow2 -n -s 1m -t none $t; \
> done
>
> short info about parameters:
> -w - do writes (otherwise do reads)
> -c - count of blocks
> -s - block size
> -t none - disable cache
> -n - native aio
> -d 1 - don't use parallel requests provided by qemu-img bench itself
Hm, actually, why not? And how does a guest behave?
If parallel requests on an SSD perform better, wouldn't a guest issue
parallel requests to the virtual device and thus to qcow2 anyway?
(I suppose the global qcow2 lock could be an issue here, but then your
benchmark should work even without -d 1.)
Max
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2018-08-16 0:51 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-07 17:43 [Qemu-devel] [PATCH 0/7] qcow2: async handling of fragmented io Vladimir Sementsov-Ogievskiy
2018-08-07 17:43 ` [Qemu-devel] [PATCH 1/7] qcow2: move qemu_co_mutex_lock below decryption procedure Vladimir Sementsov-Ogievskiy
[not found] ` <8e1cc18c-307f-99b1-5892-713ebd17a15f@redhat.com>
[not found] ` <43277786-b6b9-e18c-b0ca-064ff7c9c0c9@redhat.com>
2018-10-01 15:56 ` Vladimir Sementsov-Ogievskiy
2018-08-07 17:43 ` [Qemu-devel] [PATCH 2/7] qcow2: bdrv_co_pwritev: move encryption code out of lock Vladimir Sementsov-Ogievskiy
2018-08-07 17:43 ` [Qemu-devel] [PATCH 3/7] qcow2: split out reading normal clusters from qcow2_co_preadv Vladimir Sementsov-Ogievskiy
[not found] ` <6e19aaeb-8acc-beb9-5ece-9ae6101637a9@redhat.com>
2018-10-01 15:14 ` Vladimir Sementsov-Ogievskiy
2018-10-01 15:39 ` Max Reitz
2018-10-01 16:00 ` Vladimir Sementsov-Ogievskiy
2018-11-01 12:17 ` Vladimir Sementsov-Ogievskiy
2018-11-07 13:51 ` Max Reitz
2018-11-07 18:16 ` Kevin Wolf
2018-11-08 10:02 ` Vladimir Sementsov-Ogievskiy
2018-11-08 10:33 ` Kevin Wolf
2018-11-08 12:36 ` Vladimir Sementsov-Ogievskiy
2018-08-07 17:43 ` [Qemu-devel] [PATCH 4/7] qcow2: async scheme for qcow2_co_preadv Vladimir Sementsov-Ogievskiy
[not found] ` <08a610aa-9c78-1c83-5e48-b93080aac87b@redhat.com>
2018-10-01 15:33 ` Vladimir Sementsov-Ogievskiy
2018-10-01 15:49 ` Max Reitz
2018-10-01 16:17 ` Vladimir Sementsov-Ogievskiy
2018-08-07 17:43 ` [Qemu-devel] [PATCH 5/7] qcow2: refactor qcow2_co_pwritev: split out qcow2_co_do_pwritev Vladimir Sementsov-Ogievskiy
[not found] ` <5c871ce7-2cab-f897-0b06-cbc05b9ffe97@redhat.com>
2018-10-01 15:43 ` Vladimir Sementsov-Ogievskiy
2018-10-01 15:50 ` Max Reitz
2018-08-07 17:43 ` [Qemu-devel] [PATCH 6/7] qcow2: refactor qcow2_co_pwritev locals scope Vladimir Sementsov-Ogievskiy
2018-08-07 17:43 ` [Qemu-devel] [PATCH 7/7] qcow2: async scheme for qcow2_co_pwritev Vladimir Sementsov-Ogievskiy
[not found] ` <1c8299bf-0b31-82a7-c7c4-5069581f2d94@redhat.com>
2018-10-01 15:46 ` Vladimir Sementsov-Ogievskiy
2018-08-16 0:51 ` Max Reitz [this message]
2018-08-16 13:58 ` [Qemu-devel] [PATCH 0/7] qcow2: async handling of fragmented io Vladimir Sementsov-Ogievskiy
2018-08-17 19:34 ` Max Reitz
2018-08-17 19:43 ` Denis V. Lunev
2018-08-20 16:33 ` Vladimir Sementsov-Ogievskiy
2018-08-20 16:39 ` Max Reitz
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=13910182-771b-c5dc-26a7-0958a7241fe8@redhat.com \
--to=mreitz@redhat.com \
--cc=den@openvz.org \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.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).