Date: Fri, 11 Feb 2005 09:59:42 +0100
From: Ingo Molnar <mingo@elte.hu>
To: Matt Mackall <mpm@selenic.com>
Cc: Chris Wright <chrisw@osdl.org>, "Jack O'Quin" <jack.oquin@gmail.com>,
       Andrew Morton <akpm@osdl.org>, Christoph Hellwig <hch@infradead.org>,
       linux-kernel@vger.kernel.org, Paul Davis <paul@linuxaudiosystems.com>,
       Con Kolivas <kernel@kolivas.org>, rlrevell@joe-job.com
Subject: Re: 2.6.11-rc3-mm2
Message-ID: <20050211085942.GB3980@elte.hu>
References: <a075431a050210125145d51e8c@mail.gmail.com> <20050211000425.GC2474@waste.org> <20050210164727.M24171@build.pdx.osdl.net> <20050211020956.GC15058@waste.org> <20050211081422.GB2287@elte.hu> <20050211084107.GG15058@waste.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050211084107.GG15058@waste.org>
User-Agent: Mutt/1.4.1i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2583
Lines: 55


* Matt Mackall <mpm@selenic.com> wrote:

> > i disagree that desktop performance tomorrow will necessarily have to
> > utilize SCHED_FIFO. Today's desktop audio applications perform quite
> > good at SCHED_NORMAL priorities [with the 2.6.11 kernel that has more
> > interactivity/latency fixes such as PREEMPT_BKL].
> 
> Desktop performance tomorrow will want realtime audio AND video. 
> Think simultaneous record and playback of multiple high-definition
> video streams. There's a demand for this; my company already sells it.

Tomorrow's hardware will have enough buffering as today's hardware has
for simpler tasks. Repeat after me: it likely _wont_ _need_ SCHED_FIFO.
Running tomorrow's hardware on today's boxes indeed pushes the system to
its limits, but torrows hardware will be well-balanced just as much as
today's is - if nothing else then due to kernel drivers providing a
buffering guarantee.

think of SCHED_FIFO on the desktop as an ugly wart, a hammer, that
destroys the careful balance of priorities of SCHED_OTHER tasks. Yes, it
can be useful if you _need_ a scheduling guarantee due to physical
constraints, and it can be useful if the hardware (or the kernel) cannot
buffer enough, but otherwise, it only causes problems.

> I'm very suspicious about being able to rip out RT-LSM once it's
> introduced. [...]

yeah, i somewhat share that view. (despite all the promises from the
audio folks - if they are just half as agressive resisting removal as
they were pushing integration then it will never be removed ;-)

but i'm not sure how rlimits will contain the whole problem - can
rlimits be restricted to a single app (jackd)? The most canonical use of
rlimits is per-user (per-group), so the rlimit could end up _widening_
the effects of the hack ...

> > > The rlimit stuff is not perfect, but it's a much better fit for the
> > > UNIX model generally, which is a fairly big win. [...]
> > 
> > a 'locked up box' is as far away from the UNIX model as it gets.
> 
> Rlimits are already the favored tool for dealing with the classic UNIX
> DoS: the fork bomb. Turn off process limits, tada, locked up box.

the big difference is that process limits are finegrained and it has a
single value (unlimited) that allows the DoS - while the RT-rlimits have
_one_ value that is safe, all the other values are unsafe!

	Ingo
-
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/