From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43490) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VUCTs-0005ZQ-46 for qemu-devel@nongnu.org; Thu, 10 Oct 2013 05:24:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VUCTm-0007yg-4w for qemu-devel@nongnu.org; Thu, 10 Oct 2013 05:24:28 -0400 Message-ID: <52567220.4000105@redhat.com> Date: Thu, 10 Oct 2013 11:23:44 +0200 From: Hans de Goede MIME-Version: 1.0 References: <1381347758-5016-1-git-send-email-hdegoede@redhat.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 1/2] audio: honor QEMU_AUDIO_TIMER_PERIOD instead of waking up every *nano* second List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alex Bligh Cc: Paolo Bonzini , malc , qemu-stable@nongnu.org, qemu-devel@nongnu.org Hi, On 9 Oct 2013, at 20:42, Hans de Goede wrote: > > Now that we no longer have MIN_REARM_TIMER_NS a bug in the audio subsys has > clearly shown it self by trying to make a timer fire every nano second. > > Note we have a similar problem in 1.6, 1.5 and older but there > MIN_REARM_TIMER_NS limits the wakeups caused by audio being active to > 4000 times / second. This still causes a host cpu load of 50 % for simply > playing audio, where as with this patch git master is at 13%, so we should > backport this to 1.5 and 1.6 too. I'm still not sure when this actually started happening, but looking at RHEL-6 qemu sources to see if that has the issue too, I've learned how this problem was introduced, the audio_timer callback used to do this: qemu_mod_timer (s->ts, qemu_get_clock (vm_clock) + conf.period.ticks); instead of calling audio_reset_timer(), so in the past there were 2 mod_timer calls, one from audio_reset_timer(), which scheduled the callback to run ASAP, and one from the audio_timer callback honering conf.period.hertz. Then at some point the qemu_mod_timer call in audio_timer was replaced with calling audio_reset_timer() and we got the problem my patch fixes. Regards, Hans