i've released the latency-tracer patch for v2.6.16:
http://redhat.com/~mingo/latency-tracing-patches/latency-tracing-v2.6.16.patch
max scheduling latencies can be tracked via the enabling of
CONFIG_WAKEUP_TIMING. Tracking can be started via the resetting of the
max latency:
echo 0 > /proc/sys/kernel/preempt_max_latency
if CONFIG_LATENCY_TRACE is enabled too then an execution trace will be
automatically generated as well, accessible via /proc/latency_trace.
if CONFIG_DEBUG_STACKOVERFLOW is enabled too then the function tracer
will also track the maximum stack-footprint observed in the system, on a
per-function-call basis. New maximums are reported to the syslog
immediately. (which can be quite verbose during bootup.)
(the latency-tracer has numerous other features as well, such as
userspace-triggered kernel-tracing, irq-triggered tracing, max
preempt-off or irq-off tracing, trace-to-console-via-early-printk for
the debugging of early bootup crashes, print-trace-at-crash, and more.
See past postings and the code for details.)
Ingo
On Mon, Mar 20, 2006 at 11:13:07AM +0100, Ingo Molnar wrote:
> i've released the latency-tracer patch for v2.6.16:
>
> http://redhat.com/~mingo/latency-tracing-patches/latency-tracing-v2.6.16.patch
Thanks, it helps a lot :)
> max scheduling latencies can be tracked via the enabling of
> CONFIG_WAKEUP_TIMING. Tracking can be started via the resetting of the
> max latency:
>
> echo 0 > /proc/sys/kernel/preempt_max_latency
>
> if CONFIG_LATENCY_TRACE is enabled too then an execution trace will be
> automatically generated as well, accessible via /proc/latency_trace.
In fact that is not enough.
In include/asm-i386/timex.h, get_cycles() is defined as
static inline cycles_t get_cycles (void)
{
unsigned long long ret=0;
#ifndef CONFIG_X86_TSC
if (!cpu_has_tsc)
return 0;
#endif
#if defined(CONFIG_X86_GENERIC) || defined(CONFIG_X86_TSC)
rdtscll(ret);
#endif
return ret;
}
If one (as I did at the first attempt) selects a CPU type of
"586/K5/5x86/6x86/6x86MX", he will get nothing from /proc/latency_trace.
So does it make sense to add dependency lines like the following one?
depends on (!X86_32 || X86_GENERIC || X86_TSC)
Cheers,
Wu
* Wu Fengguang <[email protected]> wrote:
> If one (as I did at the first attempt) selects a CPU type of
> "586/K5/5x86/6x86/6x86MX", he will get nothing from
> /proc/latency_trace.
>
> So does it make sense to add dependency lines like the following one?
>
> depends on (!X86_32 || X86_GENERIC || X86_TSC)
yeah, makes sense - i've added this too and have uploaded an updated
version of the patch.
Ingo