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

[Stefan Hajnoczi]

On Wed, Feb 29, 2012 at 1:12 PM, Martin Mailand <address@hidden> wrote:
> Hi Stefan,
> you are right, the performance for the commits 0b9b128530b and 4fefc55ab04d
> are both good.
> What is the best approach to stay in the qemu-kvm.git history?

I didn't know the answer so I asked on #git on freenode:

< charon> stefanha: so just tell it that the upstream tip is good
< charon> git-bisect assumes you are looking for a single commit C
such that any commit that contains C (in its history) is bad, and any
other commit is good. if you declare up front that upstream does not
contain C, then it won't go looking there
of course if that declaration was wrong, it will give wrong results.

I think there are two approaches:

1. Side-step this issue by bisecting qemu.git instead of qemu-kvm.git.

2. First test qemu-kvm.git origin/upstream-merge and if there is no
performance issue, do: git bisect good origin/upstream-merge.  If
we're luckily this will avoid going down all the qemu.git merge trees
and instead stay focussed on qemu-kvm.git commits.

Stefan