Messages in this thread | | | Date | Fri, 11 Feb 2005 09:59:42 +0100 | From | Ingo Molnar <> | Subject | Re: 2.6.11-rc3-mm2 |
| |
* 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/
| |