All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Lieven <pl@kamp.de>
To: "Paolo Bonzini" <pbonzini@redhat.com>,
	"Benoît Canet" <benoit.canet@irqsave.net>
Cc: kwolf@redhat.com, ronniesahlberg@gmail.com,
	qemu-devel@nongnu.org, stefanha@redhat.com, mreitz@redhat.com
Subject: Re: [Qemu-devel] [PATCH 2/4] block: immediately cancel oversized read/write requests
Date: Mon, 08 Sep 2014 16:54:03 +0200	[thread overview]
Message-ID: <540DC30B.2040408@kamp.de> (raw)
In-Reply-To: <540DC059.4000907@redhat.com>

On 08.09.2014 16:42, Paolo Bonzini wrote:
> Il 08/09/2014 16:35, Peter Lieven ha scritto:
>>>>> messages. :)
>>>> So you would not throw an error msg here?
>>> No, though a trace could be useful.
>> Is there a howto somewhere how to implement that?
> Try commit 4ac4458076e1aaf3b01a6361154117df20e22215.

Thanks for the pointer.

>
>> Whats your opinion changed the max_xfer_len to 0xffff regardsless
>> of use_16_for_rw in iSCSI?
> If you implemented request splitting in the block layer, it would be
> okay to force max_xfer_len to 0xffff.

Unfortunately, I currently have no time for that. It will include some shuffling with
qiovs that has to be properly tested.

Regarding iSCSI: In fact currently the limit is 0xffff for all iSCSI Targets < 2TB.
So I thought that its not obvious at all why a > 2TB target can handle bigger requests.

To the root cause of this patch multiwrite_merge I still have some thoughts:
  - why are we merging requests for raw (especially host devices and/or iSCSI?)
    The original patch from Kevin was to mitigate a QCOW2 performance regression.
    For iSCSI the qiov concats are destroying all the zerocopy efforts we made.
  - should we only merge requests within the same cluster?
  - why is there no multiread_merge?

Peter

  reply	other threads:[~2014-09-08 14:54 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-05 16:51 [Qemu-devel] [PATCH 0/4] introduce max_transfer_length Peter Lieven
2014-09-05 16:51 ` [Qemu-devel] [PATCH 1/4] BlockLimits: " Peter Lieven
2014-09-05 16:51 ` [Qemu-devel] [PATCH 2/4] block: immediately cancel oversized read/write requests Peter Lieven
2014-09-08 13:44   ` Benoît Canet
2014-09-08 13:49     ` Paolo Bonzini
2014-09-08 13:56       ` Peter Lieven
2014-09-08 13:58         ` Paolo Bonzini
2014-09-08 14:35           ` Peter Lieven
2014-09-08 14:42             ` Paolo Bonzini
2014-09-08 14:54               ` Peter Lieven [this message]
2014-09-23  8:47                 ` Kevin Wolf
2014-09-23  8:55                   ` Peter Lieven
2014-09-23  9:09                     ` Kevin Wolf
2014-09-08 15:13               ` ronnie sahlberg
2014-09-08 15:15                 ` Paolo Bonzini
2014-09-08 15:18                   ` Peter Lieven
2014-09-08 15:27                     ` Paolo Bonzini
2014-09-08 16:18                       ` Peter Lieven
2014-09-08 16:29                         ` Paolo Bonzini
2014-09-12 11:43                           ` Peter Lieven
2014-09-18 14:12                             ` Paolo Bonzini
2014-09-18 14:16                               ` Peter Lieven
2014-09-18 14:17                                 ` Paolo Bonzini
2014-09-18 22:57                                   ` Peter Lieven
2014-09-08 15:16                 ` Peter Lieven
2014-09-05 16:51 ` [Qemu-devel] [PATCH 3/4] block/iscsi: set max_transfer_length Peter Lieven
2014-09-05 16:51 ` [Qemu-devel] [PATCH 4/4] block: avoid creating oversized writes in multiwrite_merge Peter Lieven
2014-09-18 14:13   ` Paolo Bonzini
2014-09-18 22:56     ` Peter Lieven
2014-09-19 13:33       ` Paolo Bonzini
2014-09-22  9:43         ` Peter Lieven
2014-09-22 19:06           ` Paolo Bonzini
2014-09-23  6:15             ` Peter Lieven
2014-09-23  8:59               ` Kevin Wolf
2014-09-23  9:04                 ` Peter Lieven
2014-09-23  9:32                 ` Peter Lieven
2014-09-23  9:47                   ` Kevin Wolf
2014-09-23  9:52                     ` Peter Lieven
2014-09-23 10:05                       ` Kevin Wolf
2014-09-30  7:26                         ` Peter Lieven
2014-09-30  8:03                           ` Kevin Wolf
2014-09-05 17:05 ` [Qemu-devel] [PATCH 0/4] introduce max_transfer_length ronnie sahlberg
2014-09-05 19:52   ` Peter Lieven
2014-09-05 21:22     ` ronnie sahlberg

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=540DC30B.2040408@kamp.de \
    --to=pl@kamp.de \
    --cc=benoit.canet@irqsave.net \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=ronniesahlberg@gmail.com \
    --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.