From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1MlzeK-0002dS-RP
	for qemu-devel@nongnu.org; Fri, 11 Sep 2009 02:30:24 -0400
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1MlzeG-0002c5-F4
	for qemu-devel@nongnu.org; Fri, 11 Sep 2009 02:30:24 -0400
Received: from [199.232.76.173] (port=43427 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1MlzeG-0002c2-AJ
	for qemu-devel@nongnu.org; Fri, 11 Sep 2009 02:30:20 -0400
Received: from mx1.redhat.com ([209.132.183.28]:27639)
	by monty-python.gnu.org with esmtp (Exim 4.60)
	(envelope-from <kwolf@redhat.com>) id 1MlzeF-0008Bh-Pf
	for qemu-devel@nongnu.org; Fri, 11 Sep 2009 02:30:20 -0400
Message-ID: <4AA9EE35.9020900@redhat.com>
Date: Fri, 11 Sep 2009 08:29:09 +0200
From: Kevin Wolf <kwolf@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH v3 1/2] Add bdrv_aio_multiwrite
References: <1252511618-19497-1-git-send-email-kwolf@redhat.com>
	<1252511618-19497-2-git-send-email-kwolf@redhat.com>
	<20090910224401.GB25700@lst.de>
In-Reply-To: <20090910224401.GB25700@lst.de>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Christoph Hellwig <hch@lst.de>
Cc: qemu-devel@nongnu.org

Am 11.09.2009 00:44, schrieb Christoph Hellwig:
> One thing that concerns me here is that we keep adding more memory
> allocations to the I/O path.  At least on fast SSDs even kernel memory
> allocations are a performance problem and they're much faster than
> userspace ones.  

In the non-merging case we have one additional allocation, the one for
mcb. Maybe we could do something like the AIOPool here to avoid some
mallocs.

In the merging case we need to allocate new IO vectors. I don't see a
way around this, though, and I hope that the benefit of a saved write
request outweighs the malloc costs. If not, it probably was a bad idea
to accept your suggestion to make it generic code instead of just
merging requests for qcow2.

Kevin