From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=38025 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OvZEJ-00038H-Op
	for qemu-devel@nongnu.org; Tue, 14 Sep 2010 13:23:41 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1OvZEI-0003dK-DA
	for qemu-devel@nongnu.org; Tue, 14 Sep 2010 13:23:39 -0400
Received: from mx1.redhat.com ([209.132.183.28]:45626)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <avi@redhat.com>) id 1OvZEI-0003d9-6o
	for qemu-devel@nongnu.org; Tue, 14 Sep 2010 13:23:38 -0400
Message-ID: <4C8FAF92.3090503@redhat.com>
Date: Tue, 14 Sep 2010 19:23:30 +0200
From: Avi Kivity <avi@redhat.com>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] qcow2 performance plan
References: <4C8F7394.8060802@redhat.com>
	<4C8F7BE4.5010102@codemonkey.ws>	<4C8F9087.2050005@redhat.com>
	<4C8F92D9.2000908@codemonkey.ws>	<4C8F9920.7070908@redhat.com>
	<AANLkTimtONED4Spt-i1A4bHdAfivxo3MhuECk-NAHtk3@mail.gmail.com>
	<4C8F9FDE.8050004@codemonkey.ws> <4C8FA297.2020807@redhat.com>
	<4C8FAC15.1020500@codemonkey.ws>
In-Reply-To: <4C8FAC15.1020500@codemonkey.ws>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
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.nongnu.org/archive/html/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: Anthony Liguori <anthony@codemonkey.ws>
Cc: Kevin Wolf <kwolf@redhat.com>, Stefan Hajnoczi <stefanha@gmail.com>, qemu-devel <qemu-devel@nongnu.org>

  On 09/14/2010 07:08 PM, Anthony Liguori wrote:
>> Yes, I hit this too.  So without this patch, it does serialize all 
>> allocating writes?
>
>
> Yes, but my patch is not enough as it turns out.
>
> When dealing with O_DIRECT, we have to handle RMW on our own which 
> means we need to serialize access to the same sector.
>
> The way we're planning on addressing this in the short term is to 
> break the single allocator queue into a per-L2 table queue.  So writes 
> to the same L2 would be serialized but writes to different L2s would 
> not be serialized.
>

So at least I read the code correctly.

The next step (also addressed in the qcow2 performance plan) is to batch 
writes to L2.  You'd actually expect to have many concurrent allocating 
writes to one L2.  The first is sent to disk, but the following ones 
just mark the L2 dirty.  When the write returns, it sees it's still 
dirty and goes back to disk again.

-- 
error compiling committee.c: too many arguments to function