On Tue, Feb 28, 2012 at 5:15 PM, Martin Mailand <martin@xxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
