Re: [patch] SCHED_SOFTRR starve-free linux scheduling policy ...

[Daniel Phillips]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/