From: Paolo Bonzini <pbonzini@redhat.com>
To: Peter Lieven <pl@kamp.de>
Cc: kwolf@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH 1.8 4/6] block/iscsi: set bdi->cluster_size
Date: Mon, 25 Nov 2013 15:51:09 +0100 [thread overview]
Message-ID: <529363DD.8010304@redhat.com> (raw)
In-Reply-To: <1385387840-17307-5-git-send-email-pl@kamp.de>
Il 25/11/2013 14:57, Peter Lieven ha scritto:
> + /* Guess the internal cluster (page) size of the iscsi target by the means
> + * of opt_unmap_gran. Transfer the unmap granularity only if it has a
> + * reasonable size for bdi->cluster_size */
> + if (iscsilun->bl.opt_unmap_gran * iscsilun->block_size >= 64 * 1024 &&
> + iscsilun->bl.opt_unmap_gran * iscsilun->block_size <= 16 * 1024 * 1024) {
> + bdi->cluster_size = iscsilun->bl.opt_unmap_gran * iscsilun->block_size;
> + }
I think you are mixing many different concepts:
* The optimal unmap granularity is good as a suggestion for the cluster
size of higher-level formats.
* The optimal transfer granularity (block limits page, bytes 6-7,
min_io_size in Linux) could be used to adjust the length of transfers in
"qemu-img convert". I have not really thought much about *how* to do it.
* The optimal transfer (block limits page, bytes 12-15, opt_io_size in
Linux) should not be used in "qemu-img convert", I think, unless you can
actually report performance improvements. This is because in "qemu-img
convert" we need to write the data anyway to the target. We cannot
schedule other commands between two transfers. So I don't think any
delays incurred by a very large write should matter.
The maximum transfer length (block limits page, bytes 8-11) should be
handled instead in the iSCSI driver, but I do not see the need to do
this unless we have reports of something not working.
Paolo
next prev parent reply other threads:[~2013-11-25 14:51 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-25 13:57 [Qemu-devel] [PATCH 1.8 0/6] qemu-img convert optimizations Peter Lieven
2013-11-25 13:57 ` [Qemu-devel] [PATCH 1.8 1/6] qemu-img: add support for skipping zeroes in input during convert Peter Lieven
2013-11-25 13:57 ` [Qemu-devel] [PATCH 1.8 2/6] qemu-img: fix usage instruction for qemu-img convert Peter Lieven
2013-11-25 17:21 ` Eric Blake
2013-11-26 7:01 ` Peter Lieven
2013-11-25 13:57 ` [Qemu-devel] [PATCH 1.8 3/6] qemu-img: add option to specify alternate iobuffer size Peter Lieven
2013-11-25 14:54 ` Paolo Bonzini
2013-11-25 15:01 ` Peter Lieven
2013-11-25 15:07 ` Peter Lieven
2013-11-25 15:14 ` Paolo Bonzini
2013-11-25 15:24 ` Peter Lieven
2013-11-25 15:48 ` Paolo Bonzini
2013-11-25 15:56 ` Peter Lieven
2013-11-25 13:57 ` [Qemu-devel] [PATCH 1.8 4/6] block/iscsi: set bdi->cluster_size Peter Lieven
2013-11-25 14:51 ` Paolo Bonzini [this message]
2013-11-25 15:02 ` Paolo Bonzini
2013-11-25 13:57 ` [Qemu-devel] [PATCH 1.8 5/6] qemu-img: add option to align writes to cluster_sectors during convert Peter Lieven
2013-11-25 15:11 ` Paolo Bonzini
2013-11-25 15:32 ` Peter Lieven
2013-11-25 15:50 ` Paolo Bonzini
2013-11-25 15:55 ` Peter Lieven
2013-11-25 16:02 ` Paolo Bonzini
2013-11-25 16:11 ` Peter Lieven
2013-11-25 16:34 ` Paolo Bonzini
2013-11-25 13:57 ` [Qemu-devel] [PATCH 1.8 6/6] qemu-img: add option to show progress in sectors Peter Lieven
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=529363DD.8010304@redhat.com \
--to=pbonzini@redhat.com \
--cc=kwolf@redhat.com \
--cc=pl@kamp.de \
--cc=qemu-devel@nongnu.org \
--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).