Re: [Qemu-devel] virtio-blk performance regression and qemu-kvm

[Stefan Hajnoczi]

On Tue, Feb 28, 2012 at 5:15 PM, Martin Mailand <address@hidden> wrote:
> Hi Stefan,
> I was bisecting qemu-kvm.git.

qemu-kvm.git regularly merges from qemu.git.  The history of the
qemu-kvm.git repository is not linear because of these periodic merges
from the qemu.git tree.  I think what happened is that git bisect went
down a qemu.git merge, which resulted in you effectively testing
qemu.git instead of qemu-kvm.git!

You can see this by using gitk(1) or git log --graph and searching for
the bad commit (12d4536f7d).  This will show a merge commit
(0b9b128530b999e36f0629dddcbafeda114fb4fb) where these qemu.git
commits were brought into qemu-kvm.git's history.

qemu-kvm.git
|
...
|
* merge commit (0b9b128530b999e36f0629dddcbafeda114fb4fb)
|\
| * "bad" commit (12d4536f7d911b6d87a766ad7300482ea663cea2)
| |
| ... more qemu.git commits
|
* previous commit, also a merge commit
(4fefc55ab04dd77002750f771e96477b5d2a473f)

Bisect seems to have gone down the qemu.git side of the merge at
0b9b128530b.  Instead we need to go down the qemu-kvm.git side of the
history.

The key thing is that the second git-bisect steps from qemu-kvm.git
into qemu.git history the source tree will be fairly different and
performance between the two is not easy to compare.

I suggest testing both of the qemu-kvm.git merge commits, 0b9b128530b
and 4fefc55ab04d.  My guess is you will find they perform the same,
i.e. the qemu.git commits which were merged did not affect performance
in qemu-kvm.git.  That would be evidence that git-bisect has not
located the real culprit.

Stefan