From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37228) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTwbC-0003yP-6l for qemu-devel@nongnu.org; Wed, 09 Oct 2013 12:27:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VTwb6-0005HD-6N for qemu-devel@nongnu.org; Wed, 09 Oct 2013 12:26:58 -0400 Received: from mx1.redhat.com ([209.132.183.28]:7108) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTwb5-0005H2-IT for qemu-devel@nongnu.org; Wed, 09 Oct 2013 12:26:52 -0400 Message-ID: <525583C2.2020504@redhat.com> Date: Wed, 09 Oct 2013 18:26:42 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <1381259403-7386-1-git-send-email-hdegoede@redhat.com> <52545950.5070403@redhat.com> <52545B44.70005@redhat.com> <28EE4224-856B-4DC1-8159-A0C274BD269E@alex.org.uk> <52546000.6070308@redhat.com> <6CD4D4EE-341E-48D0-98F4-D55C0D3922D4@alex.org.uk> <52546832.9040900@redhat.com> <5254701B.5070804@redhat.com> <525552D9.90407@redhat.com> <52556A35.7060300@redhat.com> <65410BFC-E64A-47FD-AC5C-6B70F69E1D06@alex.org.uk> In-Reply-To: <65410BFC-E64A-47FD-AC5C-6B70F69E1D06@alex.org.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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: Alex Bligh Cc: Hans de Goede , qemu-devel@nongnu.org Il 09/10/2013 18:19, Alex Bligh ha scritto: >> Do you also agree that the equivalent workaround, before >> > Alex's patch, was MIN_REARM_TIMER_NS (and thus 250 microseconds)? > I don't think this was the case, as if it's a timer constantly > expiring we'd have seen select() exit as soon as it was entered > by the fd poked by the signal. The signal itself was clamped to be at least 250 microseconds... > That might be far more frequent. ... it's true though that it could have been less than 250 microseconds (more precisely, 250 microseconds minus the time from qemu_mod_timer_ns to select). Since the CPU usage with Hans's patch is 100% and used to be 50%, it was also more than 1 ns that Hans's patch is using. > I think the equivalent would be something like: if the 'zero' > timeout comes from the deadline calculation (and not > nonblocking=true) then release the lock anyway. I think > that would be a reasonable approach. > > I would however like to get to the bottom of what's causing > this as even pre my changes playing sound was apparently taking > 50% CPU, which is not good. I am completely packed until the > weekend but I propose producing a timer debug patch which > will instrument what is expiring constantly (unless the > problem with spice is obvious to someone). I think Hans already debugged it to the (supposedly) 33 Hz timer that spice audio uses. If it turns out the bug is in the QEMU part of spice, I think it makes sense _not_ to include this patch at all. If it turns out to be in spice itself, then we can include it as a workaround, but still it would be nice to tune a bit the limit and not burn even more CPU time than before. Paolo