Hi Juri, sorry for the late reply (I am just back from vacations), and thanks for cc-ing me. I see you opened a bug on github about this, so I am going to add more details there, but basically I think that in order to use SCHED_DEADLINE as non-root we need to: 1) Disable the boosting mechanism (not the inheritance, just the "soft enforcement behaviour" of tasks holding mutexes) 2) Implement some mechanism to limit the amount of dl bandwidth a user can allocate to itself (I think the cgroup-based approach we discussed some time ago should be OK... If I remember well, you even had a patch implementing it :) Luca On Mon, 20 Aug 2018 10:54:20 +0200 Juri Lelli <juri.lelli@xxxxxxxxx> wrote: > On 18/08/18 15:26, Tim Blechmann wrote: > > >> audio applications typically use SCHED_FIFO. however they are > > >> rate-monotonic by design, so i wanted to evaluate how > > >> SCHED_DEADLINE behaves here. > > > > > > Right. Exactly what I started to think about lately as well. > > > > > >> > > >>> Asking because we might want to have a look at how to relax the > > >>> current privileges requirement. > > >> > > >> please :) > > > > > > Anything to try attracting new users. :-P > > > > > > More seriously, could you please describe in a bit more details > > > your specific use case? Based on JACK I guess? Is it the > > > application you are interested into public available somewhere? > > > > it could be based on JACK or natively on ALSA. furthermore the fun > > part starts when trying to distribute work to multiple threads: > > during the time slice of one audio callback (could be as low as > > 1.3ms), we need to wake helper threads and (busy?)wait to collect > > all the results. (while one of the applications is open source, > > it's not entirely straight-forward to use) > > > > for me it's more an investigation if SCHED_DEADLINE is actually > > feasible in real-world audio application these days. tommaso used > > to have a research prototype [1], built directly into JACK. however > > currently i'd be more interested in using it in ALSA. but yeah, > > it's more an investigation as SCHED_FIFO does a decent job for my > > use case ... > > I (almost) see. Thanks for the details. > > > [1] http://retis.sssup.it/~tommaso/publications/LAC-2011.pdf > > So, this was IIRC using AQuoSA hierarchical RT on EDF scheduler > implementation; which it was handy to easy the task of assigning CBS > server parameters to JACK clients (graph). > > 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? > > BTW, cc-ing Tommaso and Luca. Discussion started from > https://www.spinics.net/lists/linux-rt-users/msg19296.html
