[Techteam] XO-1.5 Kernel Update (i.e My Weekly Status)
Benjamin M. Schwartz
bmschwar at fas.harvard.edu
Mon Jul 20 17:07:14 EDT 2009
Richard A. Smith wrote:
> Benjamin M. Schwartz wrote:
>> To handle unpredictable interrupts, cpuidle uses recent history to
>> the frequency of future interrupts, and then chooses processor states to
>> meet an associated latency requirement. It seems likely to me that this
>> will avoid any need for a special idleness API.
> How will it do with an app like acoustic measure?
I see what you're saying. (This program proved a problem in the past
because it would use very little CPU while playing and recording sound,
resulting in idleness detection kicking in and turning off the CPU entirely.)
Audio playback and recording don't use userspace timers, but they do
generate a lot of interrupts. If cpuidle does something even marginally
sane with interrupt history, it should not go into a high-latency sleep
state during sound playback or recording. If it does, audio will skip,
but the CPU will be woken up by every interrupt delivered from the sound
card. (It occurs to me that this probably should've happened for the XO-1
too, but it didn't. Maybe the EC is not handling those interrupts properly?)
Hopefully, this shouldn't be a problem even if cpuidle is dumb, because
drivers can specify their latency requirements explicitly using
pm_qos_add_requirement(). During recording, the sound driver should set a
low enough interrupt latency requirement so that buffer overruns do not
occur. cpuidle will then not enter states with too high an interrupt
latency. I believe the HDA audio driver code already does this.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: OpenPGP digital signature
Url : http://lists.laptop.org/pipermail/devel/attachments/20090720/a660e0c8/attachment.pgp
More information about the Devel