Re: RT patch acceptance

[Andi Kleen <ak@muc.de>]

On Fri, May 27, 2005 at 03:56:44PM +0200, Takashi Iwai wrote:
> At 27 May 2005 15:31:22 +0200,
> Andi Kleen wrote:
> > 
> > On Fri, May 27, 2005 at 03:13:17PM +0200, Ingo Molnar wrote:
> > > 
> > > > > but it's certainly not for free. Just like there's no zero-cost
> > > > > virtualization, or there's no zero-cost nanokernel approach either,
> > > > > there's no zero-cost single-kernel-image deterministic system either.
> > > > > 
> > > > > and the argument about binary kernels - that's a choice up to vendors
> > > > 
> > > > It is not only binary distribution kernels. I always use my own self
> > > > compiled kernels, but I certainly would not want a special kernel just
> > > > to do something normal that requires good latency (like sound use).
> > > 
> > > for good sound you'll at least need PREEMPT_VOLUNTARY. You'll need 
> > > CONFIG_PREEMPT for certain workloads or pro-audio use.
> > 
> > AFAIK the kernel has quite regressed recently, but that was not true
> > (for reasonable sound) at least for some earlier 2.6 kernels and
> > some of the low latency patchkit 2.4 kernels.
> > 
> > So it is certainly possible to do it without preemption.
> 
> Yes, as Ingo stated many times, addition cond_resched() to
> might_sleep() does achieve the "usable" latencies  -- and obviously
> that's hacky.

But it's the only way to get practial(1)low latency benefit to everybody - 
not just a few selected few who know how to set the right 
kernel options or do other incarnations and willfully give up performance
and stability.

It is basically similar to why we often avoid kernel tunables - the
kernel must work well out of the box.

(1) = not necessarily provable, but good enough at least for jack et.al.

> 
> So, the only question is whether changing (inserting) cond_resched()
> to all points would be acceptable even if it results in a big amount
> of changes...

We've been doing that for years, haven't we. The main criterium
should be not to change code, but to not affect performance considerably.

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