Date: Tue, 25 Jan 2005 15:12:31 +0100
From: Ingo Molnar <mingo@elte.hu>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: "Jack O'Quin" <joq@io.com>, Paul Davis <paul@linuxaudiosystems.com>,
       Con Kolivas <kernel@kolivas.org>, linux <linux-kernel@vger.kernel.org>,
       rlrevell@joe-job.com, CK Kernel <ck@vds.kolivas.org>,
       utz <utz@s2y4n2c.de>, Andrew Morton <akpm@osdl.org>, alexn@dsv.su.se,
       Rui Nuno Capela <rncbc@rncbc.org>, Chris Wright <chrisw@osdl.org>,
       Arjan van de Ven <arjanv@redhat.com>
Subject: Re: [patch, 2.6.11-rc2] sched: /proc/sys/kernel/rt_cpu_limit tunable
Message-ID: <20050125141231.GA19539@elte.hu>
References: <200501201542.j0KFgOwo019109@localhost.localdomain> <87y8eo9hed.fsf@sulphur.joq.us> <20050120172506.GA20295@elte.hu> <87wtu6fho8.fsf@sulphur.joq.us> <20050122165458.GA14426@elte.hu> <87hdl940ph.fsf@sulphur.joq.us> <20050124085902.GA8059@elte.hu> <20050124125814.GA31471@elte.hu> <87k6q2umla.fsf@sulphur.joq.us> <41F5E727.4000208@yahoo.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <41F5E727.4000208@yahoo.com.au>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1589
Lines: 37


* 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/