linuxaudio.org

On Tue, Jun 23, 2009 at 6:19 PM, Fernando

Lopez-Lezcano wrote:
> see here for an interesting entry:

quoted text
>  https://bugzilla.redhat.com/show_bug.cgi?id=442959

that is hilarious :)
> and

quoted text
>  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  -

> 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?
>> the API looks entirely usable to me, in the sense that i could easily

quoted text
>> 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

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.

_______________________________________________

Linux-audio-dev mailing list

Linux-audio-dev@lists.linuxaudio.org

http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev