Re: [patch, 2.6.11-rc2] sched: /proc/sys/kernel/rt_cpu_limit tunable

[Ingo Molnar <mingo@elte.hu>]

* Nick Piggin <nickpiggin@yahoo.com.au> wrote:

> > This is a far better idea from an API perspective.  We can continue
> > writing to the POSIX realtime standard interfaces.  Yet users can
> > actually take advantage of them.  I like it.
> 
> This still doesn't solve your privlige problem though. If I can't
> renice something as a regular user, it makes no sense to allow such
> realtime behaviour.
> 
> I still think the ulimit patches aren't a bad idea to solve your
> privilege problem. At that point, is there still a need for
> rt_cpu_limit?

i do believe it is not robust to give unprivileged users RT priorities,
without safeguards installed. Most normal desktops have some sort of
audio playback capability, so this problem needs a robust, API-neutral
and configurable/flexible solution.

RT-LSM and rlimit privileges are configurable, API-neutral but not
robust, while rt_cpu_limit is robust but not flexible. SCHED_ISO meets
all those needs.

there's a fourth option which is simpler than SCHED_ISO: in the previous
mail i've announced the RLIMIT_RT_CPU_RATIO feature, which should meet
all these requirements as well: the security and API ease-of-use of
rt_cpu_limit, and the maximum flexibility of rlimits. (It also has the
extra bonus of enabling the tweaking/securing of existing RT classes,
which SCHED_ISO doesnt do.)

	Ingo