From: Daniel Phillips <phillips@arcor.de>
To: Mike Galbraith <efault@gmx.de>, Takashi Iwai <tiwai@suse.de>
Cc: 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: Sun, 10 Aug 2003 21:28:49 +0100 [thread overview]
Message-ID: <200308102128.49817.phillips@arcor.de> (raw)
In-Reply-To: <5.2.1.1.2.20030810182157.019c66c0@pop.gmx.net>
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.
> No matter what limit you put on the cpu usage, that amount can (xlat:
> probably will) be abused.
How? Anybody user can run an empty loop right now and it will have
approximately the same effect, i.e., it will use some cpu, big deal. The
other danger is that the latency of certain kernel threads could be
increased, e.g., kswapd, ksoftirqd, keventd. Here, a malicious softrr
application could only cause increased latency during the realtime slice, so
there's a cap on that. And anyway, why aren't those kernel threads running
with realtime priority in the first place?
While we're in here: what should be the maximum realtime priority granted to a
normal user? It should probably be another adminstrator knob.
> On my little box, I'd have to relinquish control of over 50% of my cpu at
> _minimum_ to some random application developer. (not)
It's your decision[tm]. At least you know that slowing down your kernel
compile is about the worst fallout you can expect from being wanton and
promiscuous with your chmod +x's. More precisely, if you do get rooted, it
will have nothing to do with softrr ;-)
The idea is, if the administrator decides not to let them have realtime
priority, sound apps will just have to do the best they can, with large
buffers etc, as they have been forced to until now.
> ...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.)
next prev parent reply other threads:[~2003-08-10 20:25 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 [this message]
2003-08-11 5:31 ` Mike Galbraith
2003-08-11 13:54 ` Takashi Iwai
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=200308102128.49817.phillips@arcor.de \
--to=phillips@arcor.de \
--cc=davidel@xmailserver.org \
--cc=efault@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=tiwai@suse.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).