lkml.org 
[lkml]   [2003]   [Aug]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [patch] SCHED_SOFTRR starve-free linux scheduling policy ...
Date
On Sunday 10 August 2003 18:49, Mike Galbraith wrote:
> It doesn't appear to accomplish anything other than bypassing 'you must be
> this tall (godly stature) to use this API'.

But it is a big deal. It means Linux can have superior audio performance
out-of-the-box, without having to run sound apps suid. From what I've seen,
you do not want to let a typical sound app have free reign over your machine.
Not that they're malicious, but they do seem to be breeding grounds for
buffer overflows, races, dangling pointers, etc.

> No matter what limit you put on the cpu usage, that amount can (xlat:
> probably will) be abused.

How? Anybody user can run an empty loop right now and it will have
approximately the same effect, i.e., it will use some cpu, big deal. The
other danger is that the latency of certain kernel threads could be
increased, e.g., kswapd, ksoftirqd, keventd. Here, a malicious softrr
application could only cause increased latency during the realtime slice, so
there's a cap on that. And anyway, why aren't those kernel threads running
with realtime priority in the first place?

While we're in here: what should be the maximum realtime priority granted to a
normal user? It should probably be another adminstrator knob.

> On my little box, I'd have to relinquish control of over 50% of my cpu at
> _minimum_ to some random application developer. (not)

It's your decision[tm]. At least you know that slowing down your kernel
compile is about the worst fallout you can expect from being wanton and
promiscuous with your chmod +x's. More precisely, if you do get rooted, it
will have nothing to do with softrr ;-)

The idea is, if the administrator decides not to let them have realtime
priority, sound apps will just have to do the best they can, with large
buffers etc, as they have been forced to until now.

> ...I'm sure it'll work. What I tested briefly worked fine. However, I'm
> not sure that it's a good (or bad) idea.

Well, perhaps it's time to get a word from a couple guys out there in the
trenches. Takashi, Conrad, any thoughts on the relative importance of this?
(Technical details are earlier in this thread.)

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

\
 
 \ /
  Last update: 2005-03-22 13:47    [W:0.073 / U:2.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site