29 Aug
2014
29 Aug
'14
4:28 p.m.
On 29/08/14 19:47, Fons Adriaensen wrote:
On Fri, Aug 29, 2014 at 06:33:43PM +1000, Simon Wise
wrote:
that's interesting, it seemed promising at first ... so this is for being
certain that particular and predictable sized tasks will get scheduled in time
for their own individual deadlines, and I guess finding out immediately that
something can't be guaranteed ... while most audio tasks need to be done as soon
as possible since they are of less predictable duration, are inter-dependant and
all work together towards essentially the same deadline ... so the challenge in
multi core machines with a set of audio tasks taking most of the available
processing is scheduling the tasks with the most depending on them earliest,
hence putting tasks on queues with various priorities makes a lot more sense.
Seems that 3.14 has also added a deadline-based
scheduler that is
closer to what audio needs from realtime than the extremely low
latency preemption based on priorities that the two older realtime
schedulers offer.
http://www.linuxfoundation.org/news-media/blogs/browse/2014/01/deadline-sch…
Not really.
I went to a workshop on this some weeks ago, with presentations
by the author(s) of this deadline scheduler.
I presented a short intro to Jack, what it does and how and why,
with the aim to enable a discussion on if the deadline scheduler
would be a good solution for running a dynamic set of audio apps.
The conclusion was that (apart from some specific uses in e.g.
drivers) it was not designed to solve this type of problem, and
it would quite difficult to use it in such a context.
The new scheduler is designed to run a set of periodic tasks,
with arbitrary periods and having few or no dependencies between
them, at up to 100% CPU usage, while meeting their deadlines.
Rate-proportional scheduling (shorter period -> higher priority)
can only do this up to 69% CPU use, except in some special cases
such as all periods being equal or having simple integer ratios
between them.
The situation with a set of audio apps running under Jack (or
something similar) is very different: the order in which they
have to run depends on their connections.
Another problem with the deadline scheduler as implemented is
that you can not overcommit CPU use. If P_i is the period of
task 'i' and T_i its running time, then Sum_i { T_i / P_i }
must be smaller than the number of CPUs available to the
scheduler. This is enforced by the API, where T_i, P_i and
D_i (the relative deadline) are parameters. If a task ever
tries to take more than its T_i, it will be interrupted and
have to wait until its CPU budget is updated, which will be
after a time P_i.
so it is probably very useful if you need to be certain of tasks completing and
perhaps change strategies early to avoid missing deadlines, but that isn't what
audio needs.
In fact, having tasks pre-empted like this is a very normal
way to use the scheduler. The idea is that each task should
get a defined share T_i of time in each period P_i, and meet
its deadline which is relative to the instant it becomes
runnable.
If on the other hand a task has to finish a defined amount
of work in each period (e.g process a period of audio because
others depend on the output), then its configured T_i must be
the absolute worst case time it could ever take to do that.
So to make this work with audio processes you need to *know*
their running time, and if these times are variable you must
use the worst case one. Which means that CPU use will be well
below 100%.
thanks for that explanation
Simon