linux-kernel - Deadline scheduler and audio

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Tue, 13 Oct 2015 09:47:37 +0200
From:	David Henningsson <david.henningsson@...onical.com>
To:	linux-kernel@...r.kernel.org
Cc:	juri.lelli@....com
Subject: Deadline scheduler and audio

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/