19 Jan
2006
19 Jan
'06
2:58 p.m.
Lee Revell wrote:
On Wed, 2006-01-18 at 21:22 -0800, Mike Taht wrote:
Lee,
Could you elaborate a little more on which "kernel hacking" .config
options are needed to do the latency tracing you have referred to a few
times now?
Besides the obvious "Latency Tracing (LATENCY_TRACE)", there are others
such as:
"Wakeup latency timing (WAKEUP_TIMING)" and it's associated histogram
"Non-preemptible critical section latency timing"
(CRITICAL_PREEMPT_TIMING) and it's associated histogram
"Interrupts-off critical section latency timing"
(CRITICAL_IRQSOFF_TIMING) and it's associated histogram
Each warns of increased kernel size and - more importantly - overhead
with these options enabled.
Could you provide a brief overview of:
1) what each of these options do and used for?
2) what to expect from the "increased overhead" in practice?
3) which ones are essential to provide good latency trace feedback?
I suspect the reason many people, myself included, don't already do this
is simply lack of knowledge.
Thanks,
Rick
The maximum scheduling latency was 31.177 msec.
Finding out
what caused it strikes me as an intensive exercise... and I don't
think anyone in their right mind would run a workload like this.
It's actually not hard at all, and would be interesting to know.
Just enable the latency tracing options in the kernel configuration,
reset the tracer on boot with "echo 0
/proc/sys/kernel/preempt_max_latency", and
post the contents
of /proc/latency trace after generating some xruns.
Lee