Re: SCHED_DEADLINE as user

[Tommaso Cucinotta <tommaso.cucinotta@santannapisa.it>]

[copying Alessio]

Hi,

On 20/08/2018 13:54, Tim Blechmann wrote:
> 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.

this is exactly the use-case we considered in that old paper back in LAC 2011, and let me just add that there is more 
experimentation and details and results in Giacomo's MSc thesis:

   https://retis.sssup.it/?q=node/77

FYI, we restarted activities on this use-case just recently, considering a couple of further dimensions:

1) support for heterogeneous platforms with the aim of achieving a sound support for Arm big.LITTLE on Android, and 
apply it to the Android video & audio processing pipelines;

2) proper consideration of power switching capabilities of the platform (assuming the user would block the CPU frequency 
to its maximum is not really multimedia-friendly);

3) support for multi-threaded processing workflows on multi-cores, as typically needed by (high-performance) audio 
applications, either with a single multi-threaded audio processing client, or, e.g., with JACK, with a DAG of 
computations that can take advantage of underlying multi-core processing.

In this context, we've been playing also with the hierarchical extension to SCHED_DEADLINE we sent last year on LKML

   https://lkml.org/lkml/2017/3/31/658

I hope we can share some good write-up & experimental results pretty soon about some of the above...
> 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.
>
> 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.

proper handling of task dependencies & synchronization, and associated priority inversion issues, is also an aspect 
we've been and we're still working on, as when you mix DEADLINE tasks in the picture, it's a big mess.
> 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 ...

I'm not sure I'm getting this: AFAIU, from this viewpoint, what you could get
with DEADLINE, is very similar to what you can get already with RT throttling
on RT (RR/FIFO), setting up properly CPU cgroups & limits. Why do you think
DEADLINE would allow you to avoid a watchdog thread, that you need with
RT instead ?

Thanks,

     T.

-- 
Tommaso Cucinotta, Computer Engineering PhD
Associate Professor at the Real-Time Systems Laboratory (ReTiS)
Scuola Superiore Sant'Anna, Pisa, Italy
http://retis.sssup.it/people/tommaso