On 08/20/2018 03:55 PM, Tim Blechmann wrote: >>> main audio thread: >>> while running: >>> snd_pcm_read // blocks until data is delivered from ALSA >>> wake helper(s) >>> do work() >>> sync_with_helper(s) >>> snd_pcm_write // blocks until data is delivered to ALSA >>> >>> alsa is basically driven by the hardware, which delivers/requests data >>> every ~1.3ms. > >>> distributing the work is a little tricky: to avoid excessive scheduling >>> overhead, the worker threads are typically woken up (after snd_pcm_read) >>> and the result is collected where sync_with_helper() typically boils >>> down to busy waiting. in this case, the workers as rate-monotonic in a >>> similar manner as the main audio thread. >> >> When you say "rate-monitonic", do you mean that the worker threads with >> smaller period (high rate, so) have a higher fixed-priority? If so, what >> are the other periods? > > the period will be the same period: i wake up the workers once per > period of the main thread, distribute the work and collect it at the > end. so "period" is basically the same, "runtime" a little lower. Good! Nerdy comment: In the theory, they use/we the term "rate-monotonic", in a very specific sense. It is a method to assign priority to tasks in a task-level fixed-priority scheduler (like FIFO). The tasks with shorter period will receive a higher priority. So I think that you meant that: "the workers are _periodic_ in a similar manner as the main audio thread." right? am I missing something? (well, if all tasks have the same period, they can have the same priority in the rate-monotonic assignment, but in deadline-monotonic as well (iff D=P)... so it is not the most precise term.) > >> as sync_with_helper() does a busy-wait, the "main audio thread" has a >> relative lower priority than the worker threads, right? > > typically all threads have the same priority and there will be at most N > threads for N physical CPU cores. so each thread will have a CPU to run > on and no thread will be preempted. Good! > >> So, your main wish here is to avoid having a watchdog thread to >> "throttle" misbehaving workload/setup? > > mainly ... and nerdy research if SCHED_DEADLINE is useful for audio > applications ... ;) > > >> For curiosity, what are the "time-constraints" setup used on mach? > > it's pretty similar to the SCHED_DEADLINE constraints: > > from: > https://opensource.apple.com/source/xnu/xnu-124.7/osfmk/mach/thread_policy.h.auto.html Nice, indeed very similar. So, it seems that the only thing we are missing is !root for your use-case, right? (/me wishes he could see peterz face now) -- Daniel
