Messages in this thread | | | Date | Mon, 11 Aug 2003 15:54:09 +0200 | From | Takashi Iwai <> | Subject | Re: [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/
| |