Re: [Qemu-devel] git bisect results

[Jan Kiszka <jan.kiszka@web.de>]

[-- Attachment #1: Type: text/plain, Size: 3829 bytes --]

On 2012-01-24 19:55, Erik Rull wrote:
> Jan Kiszka wrote:
>> On 2012-01-24 18:24, Erik Rull wrote:
>>> Hi all,
>>>
>>> I assume that I found a possible source of the bad usbtablet update
>>> rate.
>>>
>>> I did some git bisectioning but I didn't get a usable result due to too
>>> many merges (or maybe my little knowledge to git), so I proceeded
>>> with some
>>> manual bisectioning by manually selecting commits and tested them.
>>>
>>> The problem was that the usbtablet update-rate in qemu-kvm-1.0 was
>>> really
>>> bad compared to qemu-kvm-0.15.0.
>>
>> Did you bisect qemu or qemu-kvm?
> 
> qemu-kvm.

Using qemu would avoid having to step through qemu-kvm merges in
addition to the merges in upstream. Specifically if the issue is
independent of the tree, upstream is preferred (patch needs to go there
anyway).

> 
>>> The first commit where the cursor worked but the update rate was bad is
>>> 7cb78eec5cdf6e4131613c64cc1a29476f327242
>>>
>>> Before this commit the usbtablet didn't work (no grabbing was possible).
>>
>> That's a merge. Can you dig into the merged patches to find the one that
>> resolved the grabbing issue? Might be 21635e121a. Then that can be
>> backported while bisecting the tree for the other issue.
> 
> How can I do that (digging into the merge)? I'm not too familiar with
> git, I see only the whole merge as one commit.

gitk e.g. nicely visualizes what was merged. Provided you are in
upstream, simply checking out (git checkout <hash) a particular commit
from the merged branch can help to check the effect of that commit.

> Or do you mean digging
> manually in the single diffs that are in the patch and try each of them?
> How does the backport work? If I change something during bisecting, git
> complains that it cannot proceed due to changed files.

git reset --hard

See also man git-bisect, "automatically bisect with hot-fix" for details
on how to apply a fix while walking through the tree.

This can, of course, also be done manually if only few commits need to
be checked.

> 
>>> But in 0.15.0 it worked. So I continued searching for interesting points
>>> between these versions.
>>>
>>> One point was the SDL commit done 2011-08-05 by Jan Kiszka.
>>> There I found changes that affected the -full-screen option.
>>>
>>> So I took the version from the commit above and just started with the
>>> -full-screen option.
>>> And everything was fine (qemu-kvm-1.0 as well)! The update rate is very
>>> good with this option.
>>
>> If you go full-screen there is constant grabbing. But I do not see the
>> correlation with the update rate when in windowed mode.
>>
>>>
>>> But I was not able to find the real change that caused the bad update
>>> rate.
>>>
>>> Jan - is it possible to track down with this information the cause of
>>> the
>>> bad update rate? It seems to be related to SDL - the VNC option is
>>> working
>>> fine without -full-screen.
>>> I would like to work without the -full-screen option.
>>
>> I still cannot follow, specifically as I have XP with tablet running
>> here. Haven't noticed any problems so far, just rechecked against
>> qemu-kvm head.
>>
>> Jan
>>
> 
> Which CPU do you have on your host? I have a Core2Duo T6800 and the
> guest running on one core. There the update rate is significant worse
> than on another system with a Core i7 (guest on a single core as well),
> on the faster system it is still visible.

I have an i7. So you see an increased host load? So high that the old
CPU is at 100%?

> Maybe its related to the
> onboard graphics? I don't know, I just see the significant differences
> between fullscreen and windowed mode.

Will check if there is a difference in the load for me. That should be
CPU independent.

Jan



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]