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

[Takashi Iwai <tiwai@suse.de>]

At Sun, 10 Aug 2003 21:28:49 +0100,
Daniel Phillips wrote:
> 
> 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.
 
well, although i see also a big win by this step, too, i understand
also a same "fear" for getting the system too free for all users.
at least, the current situation is that there is no user/task
restriction at all.  so, if you set up 50% soft-RR, you'll always have
a danger that anon user takes 50% all the time.
i think it would be nice if we have additionally some user/task-base
restrictions, too.

perhaps it's a job of some wrapper library.  suppose a library which
works like utempter library: checking the calling process
path whether it's a registered one, and gives the RT and mlock
capabilities to the caller in return.  these capabilities are dropped
after executing the syscalls in the wrapper lib.
this requires CAP_SETPCAP capability and one suid-root exec binary...


> > ...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.)

ok, there are mainly two directions for audio apps.

1. player programs like xmms
2. real-time audio systems (and apps) like JACK.

so, what we'll gain by soft-RR?

in the first case, which most of us are facinig, we can have the
higher priority for the audio thread with soft-RR quite easily and
more safely.  the audio-thread needs usually woken up every 0.1 or 0.2
seconds fairly precisely.  this is a main reason of drop out in
playing mp3's.  other threads (main control, decoding, graphic, etc.)
are not necessarily scheduled with a higher priority at all.

in the second case, the higher RT-priority is a "must".  since the
whole process-chain is supposed to run in a low latency, they should
be scheduled in RT.
IMO, in this area, the soft-RR is a best choice.  it prevents a
lock-up even if one of the RT-scheduled processes gets crazy.  it
guarantees the rock-stable system as an audio workstation.

as said, i think the permission is another question.  there can be
better solutions.
but even without the (default) permission to normal users, the soft-RR
scheduler is surely a great help for RT apps.

-- 
Takashi Iwai <tiwai@suse.de>		SuSE Linux AG - www.suse.de
ALSA Developer				ALSA Project - www.alsa-project.org