From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:39586) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTxxT-0006q8-JJ for qemu-devel@nongnu.org; Wed, 09 Oct 2013 13:54:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VTxxL-0004hl-A9 for qemu-devel@nongnu.org; Wed, 09 Oct 2013 13:54:03 -0400 Received: from mx1.redhat.com ([209.132.183.28]:33976) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VTxxL-0004hf-0k for qemu-devel@nongnu.org; Wed, 09 Oct 2013 13:53:55 -0400 Message-ID: <5255982A.7000705@redhat.com> Date: Wed, 09 Oct 2013 19:53:46 +0200 From: Hans de Goede 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> <525583C2.2020504@redhat.com> In-Reply-To: <525583C2.2020504@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Paolo Bonzini , Alex Bligh Cc: qemu-devel@nongnu.org Hi, On 10/09/2013 06:26 PM, Paolo Bonzini wrote: > 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. Correction, I've been looking at timers in the spice audio path which could potentially cause this, and this one stood out. The real problem could be a completely different timer! > 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. As you said yourself before in a previous mail, at a minimum we should ensure we always unlock the iolock when called in blocking mode, to give other threads a chance to aquire it, so we need some form of my patch, or some other patch which achieves the unlocking, I welcome other proposals which have the same end result :) Regards, Hans