On Fri, Aug 29, 2014 at 11:01 AM, Fons Adriaensen <fons@xxxxxxxxxxxxxx> wrote: > On Sat, Aug 30, 2014 at 12:28:24AM +1000, Simon Wise wrote: ... >> 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. > > The most common case in our world is all tasks having the same period. > Then you schedule them on their dependencies, and nothing else. The > exception would be algorithms such as used in zita-convolver in which > part (or even most of) the work is done in larger periods, which are > all an exact multiple (even power of 2) of Jack's one. Rate-monotonic > scheduling (giving the tasks with larger periods lower priority) works > very well in that case, up to full CPU usage, provided all app use the > same mapping from period size to priority. I recently sat in on Karthik Poduval's thesis defense on the topic of Jack scheduling with the hierarchical group scheduler (I hope you don't mind the mention, Karthik). He showed great scheduling efficiency for a real-time thread and reduced jitter. Hardware locality and group scheduling looks like a great approach for real-time audio and video--this approach could handle many of the issues mentioned in this thread. For example, 1-2 ms is significant for a real-time audio thread, but 16-17 ms is the important duration for 60Hz video. One may need low latency, the other may need high throughput. The solution is: 2 different schedulers in a hierarchy, each handling different groups of processes. There can be any number of schedulers in group hierarchical scheduling, so the system processes could be handled by another (the first/original) scheduler as well. HWLoc can add to this scheme, ensuring there's no contention among different RT processes that operate on different time-scales (on multi-core systems). Aside from knowing this general scheme and principle, I'm ignorant of the fine details of kernel schedulers. I may not be able to add much more to this discussion (but I'll keep reading). _______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
