From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33896) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTemL-0000aR-3l for qemu-devel@nongnu.org; Tue, 08 Oct 2013 17:25:18 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VTemK-0000fm-6Q for qemu-devel@nongnu.org; Tue, 08 Oct 2013 17:25:17 -0400 Received: from mail.avalus.com ([2001:41c8:10:1dd::10]:45578) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTemK-0000fe-0Z for qemu-devel@nongnu.org; Tue, 08 Oct 2013 17:25:16 -0400 Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Alex Bligh In-Reply-To: <52546492.7000809@redhat.com> Date: Tue, 8 Oct 2013 22:25:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <8EE2AD26-1C32-4C69-BA89-B5C4C4D46DA2@alex.org.uk> References: <1381259403-7386-1-git-send-email-hdegoede@redhat.com> <0863CECC-BE13-4B55-8FFF-593D942A5195@alex.org.uk> <52546492.7000809@redhat.com> Subject: Re: [Qemu-devel] [PATCH] main-loop: Don't lock starve io-threads when main_loop_tlg has pending events List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Hans de Goede Cc: qemu-devel@nongnu.org, Alex Bligh On 8 Oct 2013, at 21:01, Hans de Goede wrote: >>> + /* When not non-blocking always allow io-threads to acquire the = lock */ >>> + if (timeout !=3D 0 && timeout_ns =3D=3D 0) { >>> + timeout_ns =3D 1; >>> + } >>> + >>> ret =3D os_host_main_loop_wait(timeout_ns); >>> qemu_iohandler_poll(gpollfds, ret); >>> #ifdef CONFIG_SLIRP >>=20 >> I /think/ you might mean "if (!blocking && timeout_ns =3D=3D 0)" >> as timeout can be zero on a blocking call at this stage (i.e. >> when there is a timer which has already expired. >=20 > timeout does not get modified, except by the slirp-stuff, which > won't ever set it to 0 I think. Ignoring the slirp stuff (which is hopefully irrelevant): For your patch to have any effect, timeout_ns must be zero or your timeout_ns=3D1 would not execute. timeout_ns should not be zero frequently for the reason I described. If the call to main_loop_wait is blocking (i.e. nonblocking=3D=3D0), timeout_ns should start at -1 - this is the case you described. If the call is non-blocking (as I originally thought) timeout_ns should start at zero. Then this line happens: timeout_ns =3D qemu_soonest_timeout(timeout_ns, timerlistgroup_deadline_ns( &main_loop_tlg)); If timeout_ns is zero (i.e. non-blocking, caused by timeout=3D0) this will do nothing (lack of optimisation and opacity here is down to slirp stuff). If timeout_ns is -1 (i.e. blocking, timeout=3DUINT32_MAX), then this will use the return from timerlistgroup_deadline_ns(). You said this was returning zero, which would cause os_host_main_loop_wait() to be called with a zero parameter. This would explain the symptom, and explain why the fix worked. But the question is why is timerlistgroup_deadline_ns returning zero. > But your right writing >=20 > if (!nonblocking && timeout_ns =3D=3D 0) >=20 > would be much clearer, so I'll do that in v2 of the patch. --=20 Alex Bligh