Re: SCHED_DEADLINE as user

[Daniel Bristot de Oliveira <daniel@bristot.me>]

On 08/20/2018 01:54 PM, Tim Blechmann wrote:
>> In your case - assuming you could already use DEADLINE for !root - do
>> you think you would need to use the same interface for the multiple
>> threads you are distributing work among? Or would you be fine with
>> assigning runtime/deadline for each one of those?
> 
> that's a tricky question and depends on the use-case: for me it's "good
> enough" to use something like:
> 
> 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.

Hi Tim!

> 
> 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?

as sync_with_helper() does a busy-wait, the "main audio thread" has a
relative lower priority than the worker threads, right?

> one could also use lock-free queues with semaphores to wake only as many
> threads as needed for the graph topology (which can depend on user
> input). in this case SCHED_FIFO sounds more suitable.
> --
> 
> from a practical point of view: i'm not targeting a safety critical
> system. one advantage i'm seeing of DEADLINE over FIFO/RR is that it's
> easier to prevent lockups (e.g. when a user overloads the system). in
> the linux audio world this is typically done by a watchdog thread. the
> other part of the unix world (mach) is using time-constraint threads by
> default for audio use cases. so i'd assume that DEADLINE would free me
> from the need to spawn the watchdog thread ...

So, your main wish here is to avoid having a watchdog thread to
"throttle" misbehaving workload/setup?

For curiosity, what are the "time-constraints" setup used on mach?

-- Daniel