> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
