Date: Mon, 11 Aug 2003 15:54:09 +0200
Message-ID: <s5hekzsjo5a.wl@alsa2.suse.de>
From: Takashi Iwai <tiwai@suse.de>
To: Daniel Phillips <phillips@arcor.de>
Cc: Mike Galbraith <efault@gmx.de>, Davide Libenzi <davidel@xmailserver.org>,
       Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [patch] SCHED_SOFTRR starve-free linux scheduling policy    ...
In-Reply-To: <200308102128.49817.phillips@arcor.de>
References: <5.2.1.1.2.20030810080748.019cb090@pop.gmx.net>
	<5.2.1.1.2.20030810182157.019c66c0@pop.gmx.net>
	<200308102128.49817.phillips@arcor.de>
User-Agent: Wanderlust/2.6.1 (Upside Down) SEMI/1.14.4 (Hosorogi)
 FLIM/1.14.4 (=?ISO-8859-4?Q?Kashiharajing=FE-mae?=) APEL/10.2 MULE
 XEmacs/21.4 (patch 12) (Portable Code) (i386-suse-linux)
MIME-Version: 1.0 (generated by SEMI 1.14.4 - "Hosorogi")
Content-Type: text/plain; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3209
Lines: 70

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/