From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50305) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y8YNf-0002R3-15 for qemu-devel@nongnu.org; Tue, 06 Jan 2015 12:57:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y8YNb-0000WS-O1 for qemu-devel@nongnu.org; Tue, 06 Jan 2015 12:57:22 -0500 Received: from relay.parallels.com ([195.214.232.42]:55320) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y8YNb-0008TS-Gy for qemu-devel@nongnu.org; Tue, 06 Jan 2015 12:57:19 -0500 Message-ID: <54AC21C5.40308@parallels.com> Date: Tue, 6 Jan 2015 20:56:21 +0300 From: "Denis V. Lunev" MIME-Version: 1.0 References: <1420457389-16332-1-git-send-email-pl@kamp.de> <54AA84BF.2010808@parallels.com> <20150106154357.GC23051@stefanha-thinkpad.redhat.com> In-Reply-To: <20150106154357.GC23051@stefanha-thinkpad.redhat.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH] block: limited request size in write zeroes unsupported path List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: kwolf@redhat.com, famz@redhat.com, Peter Lieven , qemu-devel@nongnu.org, mreitz@redhat.com, stefanha@redhat.com, den@openvz.org On 06/01/15 18:43, Stefan Hajnoczi wrote: > On Mon, Jan 05, 2015 at 03:34:07PM +0300, Denis V. Lunev wrote: >> Though pls consider my patch v3, it avoids allocation of 16 Mb here and >> uses only 1 Mb of memory. > > Once your patch has Reviewed-by: it will show up on my radar for merge. > > If you and Peter need a 2nd opinion in your discussions about the > fallocate series, I can look at the series in more detail myself. Just > let me know. > > Stefan > Fallocate stuff has been reviewed by Fam and I have enough feedback at the moment to start rework. He wants some simplifications at the moment. This is not a big deal. This patch is technically correct and solves the problem I have spotted. Thus it could be merged. I'll drop patch 1 in my series for the sake of this one to avoid unnecessary discussion with it. On the other hand I believe that my patch is a little bit better, it allocates only 1 MB instead of 16 here. Though I could rebase it and send it separately on top of this to discuss it independently. By the way, Stefan, do you see Acked-by: tag in your radar or it should be avoided? We are using it as review signature thanks to my prior Linux kernel experience. Regards, Den