From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:36955) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rpmoh-00087d-4U for qemu-devel@nongnu.org; Tue, 24 Jan 2012 15:18:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rpmmg-00023B-Tv for qemu-devel@nongnu.org; Tue, 24 Jan 2012 15:16:08 -0500 Received: from fmmailgate01.web.de ([217.72.192.221]:37867) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rpmmg-00022x-L0 for qemu-devel@nongnu.org; Tue, 24 Jan 2012 15:16:02 -0500 Received: from moweb001.kundenserver.de (moweb001.kundenserver.de [172.19.20.114]) by fmmailgate01.web.de (Postfix) with ESMTP id E7F6C1A99CC78 for ; Tue, 24 Jan 2012 21:15:51 +0100 (CET) Message-ID: <4F1F117A.7090405@web.de> Date: Tue, 24 Jan 2012 21:15:54 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <0N3oon-1SLIfp2hzg-00ckUZ@icpu819.kundenserver.de> <4F1EE930.40002@rdsoftware.de> <4F1EF639.8000108@siemens.com> <4F1EFEA0.2090708@rdsoftware.de> In-Reply-To: <4F1EFEA0.2090708@rdsoftware.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig9DE58C47E65A4E246AA66A7E" Subject: Re: [Qemu-devel] git bisect results List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Erik Rull Cc: "qemu-devel@nongnu.org" This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig9DE58C47E65A4E246AA66A7E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 t= oo >>> 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? >=20 > 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). >=20 >>> 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 possibl= e). >> >> That's a merge. Can you dig into the merged patches to find the one th= at >> resolved the grabbing issue? Might be 21635e121a. Then that can be >> backported while bisecting the tree for the other issue. >=20 > 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 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. >=20 >>> But in 0.15.0 it worked. So I continued searching for interesting poi= nts >>> 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 ve= ry >>> 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 >> >=20 > 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 --------------enig9DE58C47E65A4E246AA66A7E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8fEXsACgkQitSsb3rl5xRSFgCfeeDVFjPacjX+GAUfrTeroMte PuIAn3n6qs18t2ECvfJCgdkZIeYCWhYt =Pjdn -----END PGP SIGNATURE----- --------------enig9DE58C47E65A4E246AA66A7E--