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 ...
Date: Mon, 11 Aug 2003 15:54:09 +0200 [thread overview]
Message-ID: <s5hekzsjo5a.wl@alsa2.suse.de> (raw)
In-Reply-To: <200308102128.49817.phillips@arcor.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
next prev parent reply other threads:[~2003-08-11 13:57 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <Pine.LNX.4.55.0307131442470.15022@bigblue.dev.mcafeelabs.c om>
2003-07-14 7:11 ` [patch] SCHED_SOFTRR starve-free linux scheduling policy Mike Galbraith
2003-07-13 21:51 ` Davide Libenzi
2003-08-09 14:05 ` Daniel Phillips
2003-08-09 17:47 ` Mike Galbraith
2003-08-09 23:58 ` Daniel Phillips
2003-08-10 6:06 ` Mike Galbraith
2003-08-10 0:41 ` Daniel Phillips
2003-08-10 6:41 ` Mike Galbraith
2003-08-10 15:46 ` Daniel Phillips
2003-08-10 17:49 ` Mike Galbraith
2003-08-10 20:28 ` Daniel Phillips
2003-08-11 5:31 ` Mike Galbraith
2003-08-11 13:54 ` Takashi Iwai [this message]
2003-08-10 2:05 ` Roger Larsson
2003-08-10 5:43 ` Nick Piggin
2003-08-10 7:41 ` Mike Galbraith
2003-08-10 7:56 ` Nick Piggin
2003-08-10 8:18 ` Mike Galbraith
2003-08-10 9:19 ` jw schultz
2003-08-11 17:01 ` Roger Larsson
2003-08-11 17:25 ` Takashi Iwai
[not found] ` <200308100405.52858.roger.larsson@skelleftea.mail.telia.com >
2003-08-10 7:11 ` Mike Galbraith
2003-08-12 7:23 ` Rob Landley
2003-08-12 23:35 ` Pavel Machek
2003-08-13 6:26 ` Mike Galbraith
2003-08-13 9:41 ` Pavel Machek
2003-07-14 7:12 ` Davide Libenzi
2003-07-14 7:24 ` Jamie Lokier
2003-07-14 7:35 ` Davide Libenzi
2003-07-14 9:11 ` Mike Galbraith
[not found] ` <Pine.LNX.4.55.0307140004390.3435@bigblue.dev.mcafeelabs.co m>
2003-07-14 8:14 ` Mike Galbraith
2003-07-14 15:09 ` Davide Libenzi
[not found] ` <Pine.LNX.4.55.0307140805220.4371@bigblue.dev.mcafeelabs.co m>
2003-07-14 16:06 ` Mike Galbraith
2003-07-14 17:22 ` Davide Libenzi
[not found] ` <Pine.LNX.4.55.0307141015010.4828@bigblue.dev.mcafeelabs.co m>
2003-07-15 4:56 ` Mike Galbraith
2003-07-15 15:47 ` Davide Libenzi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=s5hekzsjo5a.wl@alsa2.suse.de \
--to=tiwai@suse.de \
--cc=davidel@xmailserver.org \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=phillips@arcor.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).