29 Aug
2014
29 Aug
'14
7:42 p.m.
On Fri, Aug 29, 2014 at 11:01 AM, Fons Adriaensen <fons(a)linuxaudio.org> wrote:
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).
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.