* Matt Mackall <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
