Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature

[Peter Williams <pwil3058@bigpond.net.au>]

Ingo Molnar wrote:
> * Jack O'Quin <joq@io.com> wrote:
> 
> 
>>>i'm wondering, couldnt Jackd solve this whole issue completely in
>>>user-space, via a simple setuid-root wrapper app that does nothing else
>>>but validates whether the user is in the 'jackd' group and then keeps a
>>>pipe open to to the real jackd process which it forks off, deprivileges
>>>and exec()s? Then unprivileged jackd could request RT-priority changes
>>>via that pipe in a straightforward way. Jack normally gets installed as
>>>root/admin anyway, so it's not like this couldnt be done.
>>
>>Perhaps.
>>
>>Until recently, that didn't work because of the longstanding rlimits
>>bug in mlockall().  For scheduling only, it might be possible.
>>
>>Of course, this violates your requirement that the user not be able to
>>lock up the CPU for DoS.  The jackd watchdog is not perfect.
> 
> 
> there is a legitimate fear that if it's made "too easy" to acquire some
> sort of SCHED_FIFO priority, that an "arm's race" would begin between
> desktop apps, each trying to set themselves to SCHED_FIFO (or SCHED_ISO)
> and advising users to 'raise the limit if they see delays' - just to get
> snappier than the rest.
> 
> thus after a couple of years we'd end up with lots of desktop apps
> running as SCHED_FIFO, and latency would go down the drain again.
> 
> (yeah, this feels like going back to the drawing board.)

I think part of the problem here is that by comparing each tasks limit 
to the runqueue's usage rate (and to some extent using a relatively 
short decay period) you're creating the need for the limits to be quite 
large i.e. it has to be big enough to be bigger than the combined usage 
rates of all the unprivileged real time tasks and also to handle the 
short term usage rate peaks of the task.

If the average usage rate is estimated over longer periods it will be 
lower allowing lower limits to be used.  Also if the task's own usage 
rate estimates are used to test the limits then the limit can be lower.

If the default limits can be made sufficiently small then the temptation 
to use this feature by "ordinary" applications will disappear.

I'm not an expert but I imagine that the CPU usage rates of most RT 
tasks taken over reasonably long time intervals is quite low and 
therefore the default limits could also be quite low without adversely 
effecting the programs that this mechanism is meant to help.

The sched_cpustats.[ch] files that are part of my SPA scheduler patches 
provide a cheap method of estimating per task usage rates.  They 
estimate usage rates for a task over its recent scheduling cycles but 
could be modified to provide updates every tick for the currently active 
task for use with this mechanism.

Peter
-- 
Peter Williams                                   pwil3058@bigpond.net.au

"Learning, n. The kind of ignorance distinguishing the studious."
  -- Ambrose Bierce