Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU_RATIO feature
From: Peter Williams
Date: Fri Jan 28 2005 - 17:17:18 EST
Ingo Molnar wrote:
* Jack O'Quin <joq@xxxxxx> 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@xxxxxxxxxxxxxx
"Learning, n. The kind of ignorance distinguishing the studious."
-- Ambrose Bierce
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/