From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54223) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xi38N-0000IH-Px for qemu-devel@nongnu.org; Sat, 25 Oct 2014 11:20:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xi38D-00058K-EE for qemu-devel@nongnu.org; Sat, 25 Oct 2014 11:20:03 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:51361 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xi38D-00058E-58 for qemu-devel@nongnu.org; Sat, 25 Oct 2014 11:19:53 -0400 Message-ID: <544BBF96.4040707@kamp.de> Date: Sat, 25 Oct 2014 17:19:50 +0200 From: Peter Lieven MIME-Version: 1.0 References: <1413446090-30050-1-git-send-email-pl@kamp.de> <1413446090-30050-5-git-send-email-pl@kamp.de> <5448E537.4080006@redhat.com> In-Reply-To: <5448E537.4080006@redhat.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCHv4 4/4] block: avoid creating oversized writes in multiwrite_merge List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz , qemu-devel@nongnu.org Cc: kwolf@redhat.com, pbonzini@redhat.com, ronniesahlberg@gmail.com, stefanha@redhat.com Am 23.10.2014 um 13:23 schrieb Max Reitz: > On 2014-10-16 at 09:54, Peter Lieven wrote: >> Signed-off-by: Peter Lieven >> Reviewed-by: Ronnie Sahlberg >> --- >> block.c | 5 +++++ >> 1 file changed, 5 insertions(+) >> >> diff --git a/block.c b/block.c >> index 0fbf916..9ad2287 100644 >> --- a/block.c >> +++ b/block.c >> @@ -4554,6 +4554,11 @@ static int multiwrite_merge(BlockDriverState *bs, BlockRequest *reqs, >> merge = 0; >> } >> + if (bs->bl.max_transfer_length && reqs[outidx].nb_sectors + >> + reqs[i].nb_sectors > bs->bl.max_transfer_length) { >> + merge = 0; >> + } >> + >> if (merge) { >> size_t size; >> QEMUIOVector *qiov = g_malloc0(sizeof(*qiov)); > > Reviewed-by: Max Reitz > > I feel like we should respect max_transfer_length in more than just this function, though. Every block device (or block driver) that sets a maximum transfer length should check requests against it as well, so we don't need to duplicate the same tests in the block layer functions, but maybe if at some point there are no things left to be done on the block layer, we could do that. I have on my todo to add a splitting logic to block.c to bdrv_co_do_preadv() and bdrv_co_do_pwritev(), but I agreed with Kevin to introduce this *after* 2.2. Peter