linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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.)


  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).