From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kx7KE-0000zL-S7 for qemu-devel@nongnu.org; Mon, 03 Nov 2008 16:51:07 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kx7KC-0000y9-UW for qemu-devel@nongnu.org; Mon, 03 Nov 2008 16:51:06 -0500 Received: from [199.232.76.173] (port=55895 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kx7KC-0000y1-Nl for qemu-devel@nongnu.org; Mon, 03 Nov 2008 16:51:04 -0500 Received: from fmmailgate03.web.de ([217.72.192.234]:49890) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kx7KB-0004BO-Ll for qemu-devel@nongnu.org; Mon, 03 Nov 2008 16:51:04 -0500 Message-ID: <490F723E.7070308@web.de> Date: Mon, 03 Nov 2008 22:50:54 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <490B53F0.9040200@codemonkey.ws> <490DFAA2.7040900@web.de> <490F5942.6020100@codemonkey.ws> <490F60E4.1040304@web.de> In-Reply-To: <490F60E4.1040304@web.de> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig8230689024797594B28EE0D7" Sender: jan.kiszka@web.de Subject: [Qemu-devel] Re: [5578] Increase default IO timeout from 10ms to 5s Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig8230689024797594B28EE0D7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Jan Kiszka wrote: > Anthony Liguori wrote: >> Jan Kiszka wrote: >>> Anthony Liguori wrote: >>> =20 >>>> If anyone notices a slow down, I'd check this revision. There may b= e >>>> broken bits of code out there that depends on wake up rate. I've do= ne a >>>> fair bit of testing and haven't found any but you never know. >>>> =20 >>> OK, here is one brokenness for you: Musicpal (qemu-arm-system) become= s >>> unusable, sounds is stopping for seconds, even keyboard input is >>> inpossible, including switching to the monitor console. What should I= >>> check for? Note that this board uses a ptimer to a PIT to the guest. = May >>> this make a difference here? >>> =20 I think I understood the problem: [...] timer_gettime(0, {it_interval=3D{0, 0}, it_value=3D{0, 0}}) =3D 0 timer_settime(0, 0, {it_interval=3D{0, 0}, it_value=3D{0, 250000}}, NULL)= =3D 0 --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xca8d90) =3D 0 select(24, [0 5 6 8 23], [], [], {0, 0}) =3D 0 (Timeout) ioctl(20, 0x4122, 0xbb) =3D 0 ioctl(20, 0x4122, 0x54) =3D 0 ioctl(20, 0x4122, 0x3) =3D 0 ioctl(20, 0x4122, 0) =3D 0 ioctl(20, 0x4122, 0xac) =3D 0 ioctl(20, 0x4122, 0) =3D 0 ioctl(20, 0x4122, 0x400) =3D 0 ioctl(21, USBDEVFS_IOCTL, 0xd64080) =3D 0 ioctl(20, 0x4122, 0xc000000000020400) =3D 0 semop(34242562, 0x7fff65de5960, 2) =3D 0 semop(34242562, 0x7fff65de5970, 1) =3D 0 read(19, "\1\0\0\0\0\201\377\377\321Z\2\0\0\0\0\0\'PO&\0\0\0\0\1\0\0\0\37= 7\377\377\377", 128) =3D 32 timer_gettime(0, {it_interval=3D{0, 0}, it_value=3D{0, 0}}) =3D 0 timer_settime(0, 0, {it_interval=3D{0, 0}, it_value=3D{0, 250000}}, NULL)= =3D 0 --- SIGALRM (Alarm clock) @ 0 (0) --- rt_sigreturn(0xca8d90) =3D 1 select(24, [0 5 6 8 23], [], [], {5, 0}^C There is a race between the alarm_timer firing SIGALRM and main_loop_wait reaching the safe harbor of select (with that infamous 5 second timeout). If the signal comes when already blocked in select, it will properly resume the latter immediately. But if the timer fired BEFORE that point, host_alarm_handler will only set a flag that the host timer has fired, the actual rearming will be done AFTER return from select. Ooops.... So, select should actually include the host timer as event. timerfd? Unfortunately a recent Linux-only feature :-/. I don't think we can rearm the timer from within the signal handler, at least not without running all the pending qemu timers. And that is surely not a signal handler job (qemu timer handler aren't thread-safe in general). Anyone any ideas? /me is thinking a bit more about it as well. Jan --------------enig8230689024797594B28EE0D7 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.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkkPckEACgkQniDOoMHTA+nIvQCfV6dEOn77kZs4H4EUK1a4xNJZ cbwAnRoAwvxf/efHFTyXhVP3KM4UOy0t =9hUx -----END PGP SIGNATURE----- --------------enig8230689024797594B28EE0D7--