From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:40165)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <den@virtuozzo.com>) id 1bFGpG-0006Tl-7C
	for qemu-devel@nongnu.org; Tue, 21 Jun 2016 04:14:27 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <den@virtuozzo.com>) id 1bFGpA-0000cW-3V
	for qemu-devel@nongnu.org; Tue, 21 Jun 2016 04:14:25 -0400
References: <1466435958-308-1-git-send-email-den@openvz.org>
	<45cce6cb-af87-9e2f-eeb2-4d4f258a3dc9@redhat.com>
From: "Denis V. Lunev" <den@openvz.org>
Message-ID: <5768EF9E.9010507@openvz.org>
Date: Tue, 21 Jun 2016 10:41:18 +0300
MIME-Version: 1.0
In-Reply-To: <45cce6cb-af87-9e2f-eeb2-4d4f258a3dc9@redhat.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 1/1] block: ignore flush requests when
 storage is clean
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/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: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Paolo Bonzini <pbonzini@redhat.com>, qemu-block@nongnu.org, qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>, Fam Zheng <famz@redhat.com>, Evgeny
	Yakovlev <eyakovlev@virtuozzo.com>, Max Reitz <mreitz@redhat.com>, Stefan
	Hajnoczi <stefanha@redhat.com>

On 06/21/2016 10:32 AM, Paolo Bonzini wrote:
>
> On 20/06/2016 17:19, Denis V. Lunev wrote:
>> +    /* Check if storage is actually dirty before flushing to disk */
>> +    if (!bs->dirty) {
>> +        goto flush_parent;
>> +    }
>> +    bs->dirty = false;
>> +
> This should be cleared after the flush is complete.  If you have
>
>      write begin
>      write end
>      flush #1 begin
>      flush #2 begin
>
> Then the second flush must only return after the first has finished.
>
> Paolo
Really interesting point, I have missed it. Though this case
is exactly one which we want to optimize. 2nd flush is
unnecessary and should not be sent, BUT you perfectly
correct it must return later than the first to the guest.

Have to rework. Nice catch!

Den