From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59596) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XR0Kf-0002MD-Du for qemu-devel@nongnu.org; Mon, 08 Sep 2014 10:54:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XR0KW-0004J1-DC for qemu-devel@nongnu.org; Mon, 08 Sep 2014 10:54:17 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:34655 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XR0KW-0004Ir-2j for qemu-devel@nongnu.org; Mon, 08 Sep 2014 10:54:08 -0400 Message-ID: <540DC30B.2040408@kamp.de> Date: Mon, 08 Sep 2014 16:54:03 +0200 From: Peter Lieven MIME-Version: 1.0 References: <1409935888-18552-1-git-send-email-pl@kamp.de> <1409935888-18552-3-git-send-email-pl@kamp.de> <20140908134434.GB22582@irqsave.net> <540DB3E2.6010905@redhat.com> <540DB583.4030101@kamp.de> <540DB5EB.2070705@redhat.com> <540DBEBD.9040701@kamp.de> <540DC059.4000907@redhat.com> In-Reply-To: <540DC059.4000907@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/4] block: immediately cancel oversized read/write requests List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini , =?windows-1252?Q?Beno=EEt_Cane?= =?windows-1252?Q?t?= Cc: kwolf@redhat.com, ronniesahlberg@gmail.com, qemu-devel@nongnu.org, stefanha@redhat.com, mreitz@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