Re: [patch, 2.6.11-rc2] sched: /proc/sys/kernel/rt_cpu_limit tunable

[Con Kolivas]

Ingo Molnar wrote:
> * Ingo Molnar <mingo@xxxxxxx> wrote:
>
>
> > [...] "how do we give low latencies to audio applications (and other,
> > soft-RT alike applications), while not allowing them to lock up the
> > system."
>
>
> ok, here is another approach, against 2.6.10/11-ish kernels:
>
>   http://redhat.com/~mingo/rt-limit-patches/
>
> this patch adds the /proc/sys/kernel/rt_cpu_limit tunable: the maximum
> amount of CPU time all RT tasks combined may use, in percent. Defaults
> to 80%.
>
> just apply the patch to 2.6.11-rc2 and you should be able to run e.g. 
> "jackd -R" as an unprivileged user.
>
> note that this allows the use of SCHED_FIFO/SCHED_RR policies, without
> the need to add any new scheduling classes. The RT CPU-limit acts on the
> existing RT-scheduling classes, by adding a pretty simple and
> straightforward method of tracking their CPU usage, and limiting them if
> they exceed the threshold. As long as the treshold is not violated the
> scheduling/latency properties of those scheduling classes remains.
>
> It would be very interesting to see how jackd/jack_test performs with
> this patch applied, and rt_cpu_limit is set to different percentages,
> compared against unpatched SCHED_FIFO performance.

Indeed it would be interesting because assuming there are no bugs in my 
SCHED_ISO implementation (which is unlikely) it should perform the same.

There are a number of features that it would be nice to have addressed 
if we take this route.

Superusers are unable to set anything higher priority than unprivileged 
users. Any restrictions placed on SCHED_RR/FIFO for unprivileged users 
affect superuser tasks as well. The default setting breaks the 
definition of these policies, yet changing the setting to 100 gives 
everyone full rt access.

ie it would be nice for there to be discrepancy between the default cpu 
limits and priority levels available to unprivileged vs superusers, and 
superusers' default settings to remain the same as current SCHED_RR/FIFO 
behaviour.

Cheers,
Con

Attachment: signature.asc
Description: OpenPGP digital signature