[PATCH] Preemption Latency Measurement Tool

[Robert Love]

Available at:
http://tech9.net/rml/linux/patch-rml-2.4.9-ac12-preempt-stats-1 and
http://tech9.net/rml/linux/patch-rml-2.4.10-pre12-preempt-stats-1
for 2.4.9-ac12 and 2.4.10-pre12, respectively.

This patch is provided thanks to MontaVista (http://mvista.com).

This patch enables a new kernel configure option, CONFIG_PREEMPT_TIMES,
which once enabled instructs the kernel preemption code to monitor
in-kernel latencies due to the various locking primitives and report the
20 worst recorded cases to /proc/latencytimes.

The patch obviously requires the preemption patch, available at
http://tech9.net/rml/linux

The patch won't start recording (I will change this...) until you read
from /proc/latencytimes once.  From then on, each read will return the
20 worst cases and reset the log.  Nonetheless, you don't want this in
the kernel if you don't plan to do use it, and I do _not_ want it
enabled during benchmarks.

The proc interface is fairly verbose.  It will give you a measurement of
the latency, what is causing the latency, the file line number and
filename where the lock (or whatever) began and the same for where it
ended.

The point is to track down long held locks and other problems that are
causing poor response.

Thus, most of you CC have noticed certain situations wherein even with
preemption you see high latencies (most of you with mp3 playback).  I
ask that, if you get the chance, to play with this patch and measuring
some latencies.  See where bad values lie.  Get a feeling for your
system... most of your latencies should be very small.  Right now, I
just read a sampling of my 8000 worst cases and the worst was 600us --
this is not bad.  Things over 5000us are interesting, especially if
consistent.

I appreciate any comments.  CC me and the list.  Enjoy.

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