Deadline scheduler and audio

[David Henningsson <david.henningsson@canonical.com>]

Hi LKML,

I had a talk a Linuxcon Europe last week about the deadline scheduler 
from an audio developer's perspective. The talk was AFAIK not recorded 
but the slides are here [1]. I've also had a few email conversations 
with Juri Lelli (thanks!) who suggested to follow up on LKML after the talk.

In short, the main thesis of the talk is that the deadline scheduler's 
requirement of entering a runtime (in time units) can be a difficult 
question to answer, for a variety of reasons:

  * CPU capacity changes (e g the kernel changes frequency dynamically, 
or in the case of big.LITTLE even moves to a core with different 
characteristics)

  * The software itself need to adapt to changes in the audio pipeline. 
This might require a temporary "boost" that's greater than the normal 
runtime, and might also occur when the current period's runtime has 
already been consumed.

For the latter problem someone in the audience suggested to temporarily 
change the thread to SCHED_FIFO, and then back to SCHED_DEADLINE when 
normal operations are resumed. An open question is whether we can do 
better than that?

  * In addition, I raised the question of how much time in PREEMPT_OFF 
would count as a bug. This might be an impossible question to answer for 
all use cases, but even a ballpark figure for typical laptop hardware 
would be better than nothing. 100 us? 1 ms? 10 ms? 100 ms? I think most 
of us would think spending, say, 10 seconds in PREEMPT_OFF would be 
quite bad - but is there anything that says that a driver should not do 
that?

-- 
David Henningsson, Canonical Ltd.
https://launchpad.net/~diwic

[1] 
http://events.linuxfoundation.org/sites/events/files/slides/deadline%20audio%20-%20Linuxcon%20EU%202015.pdf