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

[Nick Piggin]

On Wed, 2005-01-26 at 16:27 -0600, Jack O'Quin wrote:
> Ingo Molnar <mingo@xxxxxxx> writes:
> 
> >  - exported the current RT-average value to /proc/stat (it's the last 
> >    field in the cpu lines)
> 
> > e.g. the issue Con and others raised: privileged tasks. By default, the
> > root user will likely have a 0 rlimit, for compatibility. _But_ i can
> > easily imagine users wanting to put in a safety limit even for
> > root-owned RT tasks by making the rlimit 98% or so. Nonprivileged users
> > would have this rlimit at say 20% in a typical desktop distribution.
> 
> That seems rather small.  CPU starvation is not generally much of a
> problem on desktop machines.  If that (single) user wants to eat up
> 70% or 80% of the CPU, that's not likely to be a problem.  Mac OS X
> allows 90% on their desktop systems.
> 

Just a bit off the topic of this sub-thread...

I'm a bit concerned about this kind of policy and breakage of
userspace APIs going into the kernel. I mean, if an app is
succeeds in gaining SCHED_FIFO / SCHED_RR scheduling, and the
scheduler does something else, that could be undesirable in some
situations.

Secondly, I think we should agree upon and get the basic rlimit
support in ASAP, so the userspace aspect can be firmed up a bit
for people like Paul and Jack (this wouldn't preclude further
work from happening in the scheduler afterwards).

And finally, with rlimit support, is there any reason why lockup
detection and correction can't go into userspace? Even RT
throttling could probably be done in a userspace daemon.

Nick



-
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/