Re: Where is RLIMIT_RT_CPU?

[Esben Nielsen]

On Mon, 17 Jul 2006, Jean-Marc Valin wrote:

> > Who said suid root? What about suid realtime or suid audio?
>
> Still, I don't see what you gain by making them setuid $group vs
> allowing member(s) of $group to use rt scheduling.
>
> > 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.
>
> This issue can also happen if you start 10 suid rt apps. It's the
> responsibility of the user to make sure there's no bad interaction. The
> reason we want a limit is to make sure the system remains relatively
> responsive (not just up). In the ideal case (not sure it's possible),
> the scheduler would make sure that non-root rt apps wouldn't get (on
> average) more CPU than they would get running at normal priority. i.e.
> if there are 3 tasks competing and you start a rt task, then that task
> couldn't get more than 25% CPU. Of course, it may not be possible to do
> that perfectly, but anything remotely close would be pretty good.
>
> In any case, most audio (and probably other) applications tend to only
> require a very small amount (<10%) of CPU to run properly. I'd be quite
> happy is my system was configured to allow me to run rt tasks as long as
> the total doesn't exceed 30% CPU.
>
> > 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.
>
> I understand that, but adding artificial restrictions (to setuid audio
> apps) isn't going to help.
>
> > 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).
>
> Why not? It could be nice as well if someone wants to implement that.
> I'd already be quite happy to just have basic control on the CPU time.
>
> > 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!)
>
> How about simply giving rt rights to whomever is logged on the console?
> That's the user that really counts since he's (usually) next to the
> audio device.
>
> > We have discussed that total lock-up can be prevented with a simple
> > watchdog. That solution doesn't need anything added into the scheduler.
>
> As I mentioned earlier, it's not about total lock-up, but having things
> run relatively smoothly and (if possible?) even fairly.
>
> 	Jean-Marc

The more I think about it the more it looks like you want a nice -40 task, 
not a real-time task. The basic behaviour you want is a task which can 
wake up and get the cpu almost immediately, but if it starts to use too 
much CPU it looses that privilige. That is you want moving priorities 
just as a normal SCHED_OTHER tasks. The only difference is that you want 
it to start further up the scale than usual so it takes much longer before 
the scheduler has moved it down to a priority, where it has to compete 
with other tasks. Maybe it is already enough to run your audio application 
at nice -20 ?

When you are not developing for a specific CPU and/or the your application 
isn't the only RT application on the system, you can't use real-time
scheduling anyway, it simply doesn't make much sense. Using a very high
SCHED_OTHER priority would probably work much better. Leave the 
RT talk for the controlled embedded applications, where the developers (are 
supposed to) know and test the whole system.

I also think that Joe user who is locked into the console should only be able
to start specific applications with extraordinary priorities. That is, it
should not be enough to look at his permissions, but look at the permissions
of the program he wants to run. Therefore a suid system is the right thing to
make.

Esben

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