* Peter Williams <[EMAIL PROTECTED]> wrote:
Oops, after rereading the patch, a task that set its RT_CPU_RATIO rlimit to zero wouldn't be escaping the mechanism at all. It would be suffering maximum throttling. [...]
my intention was to let 'limit 0' mean 'old RT semantics' - i.e. 'no RT CPU time for unprivileged tasks at all', and only privileged tasks may do it and then they'll get full CPU time with no throttling.
so in that context your observation highlights another bug, which i fixed in the -D7 patch available from the usual place:
http://redhat.com/~mingo/rt-limit-patches/
not doing the '0' exception would make it harder to introduce the rlimit in a compatible fashion. (My current thinking is that the default RT_CPU rlimit should be 0.)
I'd suggest making the default 100% and only allow non privileged users to set a real time policy if the tasks RT_CPU_RATIO is BELOW some (possibly configurable via sysfs or sysctl) limit. This will have the desired effect that tasks given RT status via the normal means will be unaffected.
I'd also like to suggest that you change the units from parts per hundred (a.k.a. percent) to parts per thousand. In addition to giving better control granularity this will be a better match to HZ on most systems giving better efficiency.
Peter -- Peter Williams [EMAIL PROTECTED]
"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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
