Re: Latency results with 2.6.10 - looks good

Ingo Molnar
2005-01-04T10:05:55Z

* 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