On Thu, 2006-01-19 at 13:57 -0500, Rick Wright wrote:
> Lee Revell wrote:
>
> >On Wed, 2006-01-18 at 21:22 -0800, Mike Taht wrote:
> >
> >
> >>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
> >
> >
> >
> >
> 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.
Enable them all but leave the histograms disabled.
Don't worry about the overhead, this is just for debugging.
Lee
Received on Fri Jan 20 00:15:08 2006
This archive was generated by hypermail 2.1.8 : Fri Jan 20 2006 - 00:15:08 EET