From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KzBO7-0002Ai-3H for qemu-devel@nongnu.org; Sun, 09 Nov 2008 09:35:39 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KzBO6-0002AM-Du for qemu-devel@nongnu.org; Sun, 09 Nov 2008 09:35:38 -0500 Received: from [199.232.76.173] (port=59434 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KzBO6-0002AG-8s for qemu-devel@nongnu.org; Sun, 09 Nov 2008 09:35:38 -0500 Received: from mx2.redhat.com ([66.187.237.31]:32994) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KzBO6-00032d-0M for qemu-devel@nongnu.org; Sun, 09 Nov 2008 09:35:38 -0500 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id mA9EZbVA029287 for ; Sun, 9 Nov 2008 09:35:37 -0500 Message-ID: <4916F536.1070009@redhat.com> Date: Sun, 09 Nov 2008 16:35:34 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH 0/4] qcow2: Improve cluster refcount update References: <1225990556.6576.10.camel@frecb07144> <49133D17.3050100@codemonkey.ws> <1226047453.4046.4.camel@frecb07144> <491449C4.4070500@codemonkey.ws> <1226070063.4046.56.camel@frecb07144> <491460D2.4060203@codemonkey.ws> In-Reply-To: <491460D2.4060203@codemonkey.ws> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Anthony Liguori wrote: > Laurent Vivier wrote: >> Le vendredi 07 novembre 2008 =C3=A0 07:59 -0600, Anthony Liguori a =C3= =A9crit : >> In all cases #1 is totally useless as it is only cosmetic. >> >> #2 improves performance without aligned buffers and with "cache" set t= o >> default value. >> =20 > > I'm currently rewriting the block-raw-posix.c O_DIRECT support. I'll=20 > commit your patches once I finish that. > > I'm switching everything to use the aio functions, introducing a=20 > memory pool so that we can efficiently allocate memory for new=20 > requests without having unbounded memory allocation, and switching all=20 > the synchronous functions to use the aio functions. What about locking? If clusters are already allocated and we don't need=20 COW things are simple (and a global lock should suffice, provided it's=20 released before the io is actually submitted), but are you planning to=20 parallelize the metadata paths as well? --=20 error compiling committee.c: too many arguments to function