From: Paolo Bonzini <pbonzini@redhat.com>
To: Hans de Goede <hdegoede@redhat.com>
Cc: malc <av1474@comtv.ru>,
qemu-stable@nongnu.org, Alex Bligh <alex@alex.org.uk>,
qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH 1/2] audio: honor QEMU_AUDIO_TIMER_PERIOD instead of waking up every *nano* second
Date: Thu, 10 Oct 2013 11:35:11 +0200 [thread overview]
Message-ID: <525674CF.10907@redhat.com> (raw)
In-Reply-To: <52567220.4000105@redhat.com>
Il 10/10/2013 11:23, Hans de Goede ha scritto:
> 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.
The first broken version seems to be 0.14.0:
commit 39deb1e496de81957167daebf5cf5d1fbd5e47c2
Author: malc <av1474@comtv.ru>
Date: Thu Nov 18 14:30:12 2010 +0300
audio: Only use audio timer when necessary
Originally proposed by Gerd Hoffmann.
Signed-off-by: malc <av1474@comtv.ru>
Acked-by: Gerd Hoffmann <kraxel@redhat.com>
next prev parent reply other threads:[~2013-10-10 9:35 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-09 19:42 [Qemu-devel] [PATCH 1/2] audio: honor QEMU_AUDIO_TIMER_PERIOD instead of waking up every *nano* second Hans de Goede
2013-10-09 19:42 ` [Qemu-devel] [PATCH 2/2] audio: Lower default wakeup rate to 100 times / second Hans de Goede
2013-10-10 6:31 ` [Qemu-devel] [PATCH 1/2] audio: honor QEMU_AUDIO_TIMER_PERIOD instead of waking up every *nano* second Alex Bligh
2013-10-10 6:58 ` Hans de Goede
2013-10-10 7:02 ` Alex Bligh
2013-10-10 9:23 ` Hans de Goede
2013-10-10 9:35 ` Paolo Bonzini [this message]
2013-12-03 20:03 ` [Qemu-devel] [Qemu-stable] " Michael Roth
2013-12-03 21:17 ` Alex Bligh
2013-12-03 22:00 ` Michael Roth
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=525674CF.10907@redhat.com \
--to=pbonzini@redhat.com \
--cc=alex@alex.org.uk \
--cc=av1474@comtv.ru \
--cc=hdegoede@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-stable@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.