[LAD] [ANNOUNCE] Safe real-time on the desktop by default; Desktop/audio RT developers, read this!

[Fernando Lopez-Lezcano]

On Tue, 2009-06-23 at 18:44 -0400, Paul Davis wrote:
> On Tue, Jun 23, 2009 at 6:19 PM, Fernando
> Lopez-Lezcano<nando at ccrma.stanford.edu> wrote:
> 
> > see here for an interesting entry:
> >  https://bugzilla.redhat.com/show_bug.cgi?id=442959
> 
> that is hilarious :)
> 
> > and
> >  http://bugzilla.kernel.org/show_bug.cgi?id=10361
> >  (referenced inside the previous ticket)
> > this is when it was apparently added to the Fedora kernels:
> > --------
> > * Fri Apr 18 2008 Kyle McMartin <kmcmartin at redhat.com> -
> > Enable CONFIG_RT_GROUP_SCHED (#442959)
> > --------
> >
> > There's something else I'm missing because I'm still able to run rt as a
> > non-root user even though I have all this stuff. Is Fedora configuring
> > this somewhere else? Is this overriden by something else?
> 
> this seems deeply odd. i am also in that same situation. it seems that
> something *must* be overriding it, but what?

I have no idea yet. Or maybe there is some other configuration that
needs to be done before it is activated. 

Or. 

Maybe it is not working at all and we are not getting rt, we have no
error message and have not noticed it :-) ;-P

> >> the API looks entirely usable to me, in the sense that i could easily
> >> imagine a GUI control panel for this that would be comprehensible to
> >> most users.
> >
> > I think the idea is no control panel :-)
> 
> yeah, i note that in the second bug report there, peter z. makes some
> comments about RT scheduling that are not entirely accurate for our
> use case.
> we are aiming at deterministic behaviour by each client in a JACK
> graph, but we don't actually expect determinism across time (e.g. as
> clients are started and stopped). we're happy to eat 95% of the CPU
> time, even if we generally expect the typical figure to be more like
> 10%. this tends  to force JACK towards a cgroup that has a perhaps
> unreasonably large allocation, and a misleading one. AFAICT, the
> Sum(all cgroup runtime) cannot exceed the rt sched period. So you
> cannot set things up to allow "JACK" to get 95% and <other RT stuff>
> to get 95% and just have stuff break if you try to do both. this is
> good and bad - its an accurate reflection of resource reservation
> policy, but it doesn't actually reflect what a regular user may want -
> running two RT subsystems at different times without reconfiguring
> their cgroups. of course, i have no idea what those two RT subsystems
> might be, so its a bit moot.

I imagine configuring this so that all rt usage is in one bag if
possible (both root and nonroot processes are counted in the same bin).
There is no need in our usage case to differentiate, and in fact it is
impossible. 

-- Fernando