Re: Latency results with 2.6.10 - looks good

[Ingo Molnar <mingo@elte.hu>]

* Lee Revell <rlrevell@joe-job.com> wrote:

> Followup: other audio users have confirmed that 2.6.10 is the best
> release yet latency-wise.  It works most of the time at 64 frames
> (~1.33ms latency).
> 
> Now, the bad news: there are still enough xruns to make it not quite
> good enough for, say, a recording studio; as we all know with realtime
> constraints the worst case scenario is important.  As expected the RT
> kernel beats it by a wide margin.  I have attached some numbers,
> excerpted from a post by Rui on the JACK list.  The JACK test used was
> described previously on this list.
> 
> Ingo, what are your plans for pushing more of the RT patch set
> upstream? It seems that the soft/hardirq threading and voluntary
> preemption (turning the might_sleep checks into preemption points) are
> required to further improve the latency of the standard kernel.  These
> are well tested at this point and also zero cost for users who don't
> enable them. I think if these features go upstream before 2.6.11 then
> we can say all of the issues Paul raised, in that post months ago that
> led to the VP patches, will be put to rest.

for 2.6.11 we have dozens of scheduler patches queued in -mm that do
half of the work necessary for the rest of -RT. I'll split out more
stuff from -RT once the scheduler queue in -mm gets smaller (i.e. once
it gets merged upstream), but there's a natural limit to the rate of
merging in a given subsystem, if we push things too hard it will
deteriorate.

also, there's the necessary merging of preempt-bkl patch. It makes
little sense to add the more advanced stuff when the BKL is allowed to
generate up to ~200 milliseconds latencies. Hardirq and softirq
threading would be the next step after that point.

	Ingo