All of lore.kernel.org
 help / color / mirror / Atom feed
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 3/6] qemu-img: add option to specify alternate iobuffer size
Date: Mon, 25 Nov 2013 16:48:55 +0100	[thread overview]
Message-ID: <52937167.2050508@redhat.com> (raw)
In-Reply-To: <52936BB0.1020608@kamp.de>

Il 25/11/2013 16:24, Peter Lieven ha scritto:
> On 25.11.2013 16:14, Paolo Bonzini wrote:
>> Il 25/11/2013 16:07, Peter Lieven ha scritto:
>>>>> since the convert process is basically a sync operation it might
>>>>> be benificial in some case to change the hardcoded I/O buffer
>>>>> size to an alternate (greater) value.
>>>> Do you really need the extra knob?  You can just add to BlockLimits the
>>>> optimal transfer length, and use it unconditionally.
>>> If you say patch 5 and 3 are ok. What could be done is to remove
>>> this knob and increase the iobuf_size to cluster_size if cluster_size
>>> is greater.
>> Yes, that makes sense because it avoids unnecessary COW.
>>
>>> I do not want to increase the default iobuf size to anything
>>> greater than 2MB. I do not know why this was choosen, but maybe
>>> there was a reason for it.
>> I think it is fine to increase it to the cluster_size or even to the
>> optimal transfer length (new BlockLimits field).
> okay scsi speaking:
>  bs->bl.optimal_transfer_length = max(iscsilun->bl.opt_xfer_len,
> iscsilun->bl.opt_unmap_gran) ?

I was thinking more of

  bs->bl.optimal_transfer_length = lun2qemu(iscsilun->bl.opt_xfer_len);

 ...
 iobuf_size =
      max(bs->bl.optimal_transfer_length, cluster_sectors)*512;
 iobuf_size = min(16MB, max(2MB, iobuf_size));

> bdi->cluster_size as in Patch 3?

Yes, that one's fine.

>> * clamp maximum size to optimal transfer length.
> or increase it if its larger. for the dell equallogic storages we use
> the opt_unmap_gran
> is 15MB!!!

You're right, maximum size is really bounded anyway by iobuf_size.

>> * then, round final sector down to unmap granularity
> okay, i will try your modification to only round down the last sector.
> would you use bdi->cluster_size or the unmap alignment field from the
> bs->bl?

bdi->cluster_size.  The qemu-img reason for the rounding is to avoid
unnecessary COW, which is what bdi->cluster_size is about.  It just so
happens that it helps your benchmark too. :)

Paolo

> Peter

  reply	other threads:[~2013-11-25 15:49 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 [this message]
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
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=52937167.2050508@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.