Re: i5 Hyper-Threading, BIOS settings and Arch n00b pointers

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Sound]     [ALSA Users]     [Pulse Audio]     [ALSA Devel]     [Sox Users]     [Linux Media]     [Kernel]     [Photo Sharing]     [Gimp]     [Yosemite News]     [Linux Media]

  Powered by Linux