Re: [PATCH] Preemption Latency Measurement Tool

[Robert Love <rml@tech9.net>]

On Sat, 2001-09-22 at 03:22, Andre Pang wrote:
> arrgh!  i just realised my script buggered up and was producing the same
> graph for all the results.  please have a look at the page again, sorry.

no problem...

> apart from that, i'm still confused.  compared to other graphs produced
> by the latencytest program, my system seems to have huge latencies.
> unless i'm reading it wrongly, the graph is saying that i'm getting
> latencies of up to 30ms, and a lot of overruns.  compare this to
> 
>     http://www.gardena.net/benno/linux/audio/2.4.0-test2/3x256.html
> 
> which shows latencytest on 2.4.0-test2, and
> 
>     http://www.gardena.net/benno/linux/audio/2.2.10-p133-3x128/3x128.html
> 
> which are the results for latencytest on 2.2.10.  admittedly these
> kernels are much older, but i'm consistently getting far more latency
> than those kernels.  that's the bit i'm confused about :)  i've tried
> Andrew Morton's low-latency patches as well, to no avail.  i've made
> sure i've tuned my hard disks correctly, and i don't have any other
> realtime processes running.
> 
> am i concerned with a different issue than the one you're addressing?

No, I understand now.  I honestly don't know what to say about your
results.

You are right, those older kernels are showing much better response
times than your kernel.  One would think your newer kernel, with
preemption or low-latency patch, would be an improvement.

I honestly don't know what to tell you.  It could be a piece of hardware
(or, more accurately) its driver ... 

the /proc/latencytimes output shows us that no single lock is accounting
for your bad times.  In fact, all your locks aren't that bad, so...

maybe the problem is in the "overruns" -- I don't know what that means
exactly.  maybe someone else on the list can shed some light? 
otheriwse, you can email the author perhaps.

With whatever buffer or whatnot is overrunning (and you are getting a
bit of them, compared to those other URLs you posted), something is
stalling or repeating.

> > the preemption-test patch is showing _MAX_ latencies of 0.8ms through
> > 12ms.  this is fine, too.
> 
> yep, i agree with that ... so why is latencytest showing scheduling
> latencies of > 30ms?  i get the feeling i'm confusing two different
> issues here.  from what i understand, /proc/latencytimes shows the
> how long it takes for various functions in the kernel to finish, and
> the latencytest result shows how long it takes for it to be
> re-scheduled (represented by the white line on the graph).

Pretty much.

/proc/latencytimes shows you how long specific locks are held in the
kernel, so this isn't the same as how long certain functions take (which
could be longer or shorter).  The reason for showing lock duration is
that preemption (with the preemptible kernel patch) can not occur during
a lock for concurrency reasons, so we want to find long-held locks and
try to find a solution to them.

latencytest does indeed show scheduling latency.  it tries to show you
how well the system can keep up with the audio buffer.  with a
preemptible kernel, you can reduce this latency to a very small number,
baring any large locks (from above).

latencytest's latency is a function of the sum of the latencies reported
by /proc/latencytimes. thus, a bad latency in latencytest could be
caused by what you see in /proc/latencytest.  you would think we would
see one or two long locks screwing everything up, but we do not.

I would try to see what the overruns mean exactly, and see if any
hardware drivers could be at fault (right now we don't report time with
interrupts disabled in /proc/latencytimes, which could be a factor too).

-- 
Robert M. Love
rml at ufl.edu
rml at tech9.net