Re: [patch, 2.6.11-rc2] sched: RLIMIT_RT_CPU feature, -D7

[Peter Williams]

Ingo Molnar wrote:
> * Peter Williams <pwil3058@xxxxxxxxxxxxxx> 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                                   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/