Date:	Sun, 16 Jul 2006 13:20:40 +0100 (BST)
From:	Esben Nielsen <nielsen.esben@...glemail.com>
To:	Jean-Marc Valin <Jean-Marc.Valin@...erbrooke.ca>
cc:	Esben Nielsen <nielsen.esben@...glemail.com>,
	Lee Revell <rlrevell@...-job.com>,
	Arjan van de Ven <arjan@...radead.org>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>
Subject: Re: Where is RLIMIT_RT_CPU?

On Sun, 16 Jul 2006, Jean-Marc Valin wrote:

>> You can't have "random" users scheduling thing at real-time priorities.
>> A real-time system can only work if it is set up as whole and all
>> real-time tasks are taken into consideration. If you allow a user to start
>> another real-time task, that task might destroy the real-time properties
>> of all the rest by taking too much cpu.
>>
>> As I see it the only thing you can do is to use sudo to run anything,
>> which needs real-time priority, with higher priviliges, than what a normal
>> user have. Then he can only start specific audio programs and can't crash
>> the system (unless those programs have a bug).
>
> I though we were past that point a long time ago. Of course you don't
> want *any* random user to have access to rt scheduling. However, you
> *do* want the user logged-in on the console be allowed to run tasks with
> rt priority (within some limits). Why? Because 1) you don't want to give
> root access to any user who needs RT for some apps and 2) you don't want
> to make all these apps suid root either.
>

Who said suid root? What about suid realtime or suid audio?

> Think about it, would you really feel safe with your sound daemon,
> Ekiga/Gnomemeeting, jackd, Amarok, mplayer, ... all being run setuid
> root. Yet all these apps (and many others) can benefit from being
> allowed a few percent CPU running at rt priority. Not to mention the
> fact that you may actually want to do rt *development* as a regular
> user. That's why people have come up with realtime-lsm, and more
> recently, with SCHED_ISO and rt-limit. What's currently missing is just
> the tiny bit that prevents the user from locking up the machine. Even
> that one was done by Ingo, but unfortunately not merged in the mainline
> kernel. Controlled properly, access to rt scheduling is no more
> dangerous (and probably less) than fork(), malloc() or mlock(), all of
> which can lock up a machine efficiently if unlimited use is allowed.

My point is not that they can lock up the machine. My point is that you 
just can't add a rt task to a rt system! A rt-system consists of a fixed 
set of threads, which in worst case can meet it's deadlines. If you add 
just one task you might break the whole system. Only someone with overview 
of the whole system can add those tasks.

It is very simple if you have only a audio application or only a driver 
needing low latencies. What if you have both? You have to make sure that 
the higher priority one leaves enough cpu for the lower priority one. And 
it is not a question of using a low percentage of cpu. It is a question of 
how long the cpu is used in one go and how often it can happen within the 
critical timeframe of the lower priority application.

You can make a system which checks that but it is much harder to do than 
a moving average. The only thing which makes sense is (a) square filter(s)
with a width equal to the required latency of the lower priority task(s).

So the sys-admin should somehow be able to give the right either to 
specific (audio) applications with specific priorities or a developer whom 
he trusts (and it does not make sense to give it to both as they would 
then mess it up for each other!)

We have discussed that total lock-up can be prevented with a simple 
watchdog. That solution doesn't need anything added into the scheduler.

Esben

>
> 	Jean-Marc
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists