[LAU] i5 Hyper-Threading, BIOS settings and Arch n00b pointers

Simon Wise simonzwise at gmail.com
Fri Aug 29 14:28:24 UTC 2014


On 29/08/14 19:47, Fons Adriaensen wrote:
> On Fri, Aug 29, 2014 at 06:33:43PM +1000, Simon Wise wrote:
>
>> 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-scheduling-314
>
> 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.

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.

>
> 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


More information about the Linux-audio-user mailing list