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
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
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
I appreciate any comments. CC me and the list. Enjoy.
-- Robert M. Love rml at ufl.edu rml at tech9.net
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to email@example.com More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/