lkml.org 
[lkml]   [2003]   [Aug]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] SCHED_SOFTRR starve-free linux scheduling policy ...
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
-
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.548 / U:4.268 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site