From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:39332)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1QZ4lY-00059z-Mc
	for qemu-devel@nongnu.org; Tue, 21 Jun 2011 13:29:34 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1QZ4lX-0004qz-8W
	for qemu-devel@nongnu.org; Tue, 21 Jun 2011 13:29:32 -0400
Received: from mx1.redhat.com ([209.132.183.28]:1033)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <lcapitulino@redhat.com>) id 1QZ4lW-0004qk-CP
	for qemu-devel@nongnu.org; Tue, 21 Jun 2011 13:29:30 -0400
Date: Tue, 21 Jun 2011 14:29:26 -0300
From: Luiz Capitulino <lcapitulino@redhat.com>
Message-ID: <20110621142926.7bc4df99@doriath>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Subject: [Qemu-devel] block: regression: savevm/delvm too slow
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: Kevin Wolf <kwolf@redhat.com>, Stefan Hajnoczi <stefanha@gmail.com>, qemu-devel <qemu-devel@nongnu.org>

I'm getting the following times when doing a savevm and delvm in current
HEAD eb47d7c5d (time in minutes, each time corresponds to a savevm/delvm run):

 savevm: 5:28m, 11:00m, 11:10m
 delvm: 4:30m, 4:40m, > 15m

Now, trying with qemu 0.13.0 I get:

 savevm: < 1:00m, 4:00m, 4:34m
 delvm: few seconds for all cases

Yes, you read it correctly, I tried with 0.13.0 because 0.14.0 also has the
bug. This is the pattern I see when I run strace against HEAD while running
the savevm command:

 pwrite(7, "\0\1\0\1\0\1\0\1\0\2\0\2\0\2\0\2\0\2\0\2\0\2\0\2\0\2\0\2\0\2\0\2"..., 65536, 196608) = 65536
 fdatasync(7)                            = 0

Ie. a fdatasync() follows every single pwrite(). Something similar also happens
with delvm. I don't see this pattern with 0.13.0.

The good news is that I've tracked it down and Mr. git bisect says that:

29c1a7301af752de6721e031d31faa48887204bd is the first bad commit
commit 29c1a7301af752de6721e031d31faa48887204bd
Author: Kevin Wolf <kwolf@redhat.com>
Date:   Mon Jan 10 17:17:28 2011 +0100

    qcow2: Use QcowCache
    
    Use the new functions of qcow2-cache.c for everything that works on refcount
    block and L2 tables.
    
    Signed-off-by: Kevin Wolf <kwolf@redhat.com>

:040000 040000 83e364185d37845bb27f1dccd1249d14cc7a9a1e 0c91964a52b5869333d4fb2cb0fa83104151359e M	block