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. 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. 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%. Ciao, -- FA A world of exhaustive, reliable metadata would be an utopia. It's also a pipe-dream, founded on self-delusion, nerd hubris and hysterically inflated market opportunities. (Cory Doctorow) _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
