Re: SCHED_DEADLINE as user

[Tim Blechmann <tim@klingt.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1977 bytes --]

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

very interesting! thanks for the links ...


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

interesting, wasn't aware of rt throttling ... (haven't done much linux
audio developments for almost 10 years). will give it another read ...

cheers,
tim


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 841 bytes --]