Re: [patch] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.36-04

[Ingo Molnar <mingo@elte.hu>]

* Lee Revell <rlrevell@joe-job.com> wrote:

> OK.  So for application triggered tracing you need LATENCY_TRACING
> enabled, as described here:
> 
> http://lkml.org/lkml/2004/10/29/312

correct, that too should still work fine - with the small change that
there's now a separate flag to active it:

	echo 1 > /proc/sys/kernel/trace_user_triggered  # default: 0

it is an orthogonal mechanism to atomicity-debugging.

since i wrote the above mail 3 months ago, a number of improvements have
been done to the tracer. There are a handful of modifier feature-flags
to the tracer, which can be used to get additional functionality. Here's
a quick summary:

	echo 1 > /proc/sys/kernel/trace_freerunning  # default: 0

will get a 'freerunning' tracer which never stops (and overwrites the
oldest entries if the trace gets full). Especially with long latencies 
this in some cases can be more informative.

this flag:

	echo 0 > /proc/sys/kernel/mcount_enabled  # default: 1

causes the tracer to record only key kernel events (schedule/wakeup
events, etc.), not every kernel function call. This might be useful if
you want to see the bigger picture and want to validate scheduling logic
on a bigger scale, spanning a much longer timeframe.

and if you have stability problems, this flag might be handy:

	echo 1 > /proc/sys/kernel/trace_freerunning  # default: 0

it will dump the current kernel trace to the kernel console if a crash
happens - obviously only useful with a serial console or netconsole. 
It's a big dump but can make some bugs much easier to debug.

on SMP:

	echo 1 > /proc/sys/kernel/trace_all_cpus  # default: 0

this flag will cause all activity from all CPUs to be included in the
trace. This can be useful if it is suspected that a particular latency
was caused not by the CPU where the latency triggers, but by some other
CPU.

	Ingo