Con Kolivas wrote: > Ingo Molnar wrote: > >> * Ingo Molnar 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. I guess it would be a simple matter of throwing on another 100 rt priorities that can only be set by CAP_SYS_NICE, and limiting selectively based on the rt_priority. Cheers, Con