Re: virtio-blk performance regression and qemu-kvm

[Martin Mailand <martin@tuxadero.com>]

Hi Stefan,
I was bisecting qemu-kvm.git.

  git remote show origin
* remote origin
   Fetch URL: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git
   Push  URL: git://git.kernel.org/pub/scm/virt/kvm/qemu-kvm.git

The bisect log is:

git bisect start
# good: [b8095f24f24e50a7d4be33d8a79474aff3324295] Bump version to 
reflect v0.15.0-rc0
git bisect good b8095f24f24e50a7d4be33d8a79474aff3324295
# bad: [e072ea2fd8fdceef64159b9596d3c15ce01bea91] Bump version to 1.0-rc0
git bisect bad e072ea2fd8fdceef64159b9596d3c15ce01bea91
# bad: [7d4b4ba5c2bae99d44f265884b567ae63947bb4a] block: New 
change_media_cb() parameter load
git bisect bad 7d4b4ba5c2bae99d44f265884b567ae63947bb4a
# good: [baaa86d9f5d516d423d34af92e0c15b56e06ac4b] hw/9pfs: Update 
v9fs_create to use coroutines
git bisect good baaa86d9f5d516d423d34af92e0c15b56e06ac4b
# bad: [9aed1e036dc0de49d08d713f9e5c4655e94acb56] Rename qemu -> 
qemu-system-i386
git bisect bad 9aed1e036dc0de49d08d713f9e5c4655e94acb56
# good: [8ef9ea85a2cc1007eaefa53e6871f1f83bcef22d] Merge remote-tracking 
branch 'qemu-kvm/memory/batch' into staging
git bisect good 8ef9ea85a2cc1007eaefa53e6871f1f83bcef22d
# good: [9f4bd6baf64b8139cf2d7f8f53a98b27531da13c] Merge remote-tracking 
branch 'kwolf/for-anthony' into staging
git bisect good 9f4bd6baf64b8139cf2d7f8f53a98b27531da13c
# good: [09001ee7b27b9b5f049362efc427d03e2186a431] trace: [make] replace 
'ifeq' with values in CONFIG_TRACE_*
git bisect good 09001ee7b27b9b5f049362efc427d03e2186a431
# good: [d8e8ef4ee05bfee0df84e2665d9196c4a954c095] simpletrace: fix 
process() argument count
git bisect good d8e8ef4ee05bfee0df84e2665d9196c4a954c095
# good: [a952c570c865d5eae6c148716f2cb585a0d3a2ee] Merge remote-tracking 
branch 'qemu-kvm-tmp/memory/core' into staging
git bisect good a952c570c865d5eae6c148716f2cb585a0d3a2ee
# good: [625f9e1f54cd78ee98ac22030da527c9a1cc9d2b] Merge remote-tracking 
branch 'stefanha/trivial-patches' into staging
git bisect good 625f9e1f54cd78ee98ac22030da527c9a1cc9d2b
# good: [d9cd446b4f6ff464f9520898116534de988d9bc1] trace: fix 
out-of-tree builds
git bisect good d9cd446b4f6ff464f9520898116534de988d9bc1
# bad: [12d4536f7d911b6d87a766ad7300482ea663cea2] main: force enabling 
of I/O thread
git bisect bad 12d4536f7d911b6d87a766ad7300482ea663cea2

-martin

On 28.02.2012 18:05, Stefan Hajnoczi wrote:
> On Tue, Feb 28, 2012 at 4:39 PM, Martin Mailand<martin@tuxadero.com>  wrote:
>> I could reproduce it and I bisected it down to this commit.
>>
>> 12d4536f7d911b6d87a766ad7300482ea663cea2 is the first bad commit
>> commit 12d4536f7d911b6d87a766ad7300482ea663cea2
>> Author: Anthony Liguori<aliguori@us.ibm.com>
>> Date:   Mon Aug 22 08:24:58 2011 -0500
> This seems strange to me.
>
> What commit 12d4536f7 did was to switch to a threading model in
> *qemu.git* that is similar to what *qemu-kvm.git* has been doing all
> along.
>
> That means the qemu-kvm binaries already use the iothread model.  The
> only explanation I have is that your bisect went down a qemu.git path
> and you therefore tripped over this - but in practice it should not
> account for a difference between qemu-kvm 0.14.1 and 1.0.
>
> Can you please confirm that you are bisecting qemu-kvm.git and not qemu.git?
>
> Stefan