Re: [PATCH] tracing: remove mentioning of legacy latency_tracefile from documentation

[Frederic Weisbecker]

On Mon, Aug 31, 2009 at 08:50:35PM +0200, Albin Tonnerre wrote:
> The latency_trace file got removed a while back by commit
> 886b5b73d71e4027d7dc6c14f5f7ab102201ea6b. This patch fixes the
> documentation to stop mentioning it.
> 
> Signed-off-by: Albin Tonnerre <albin.tonnerre@xxxxxxxxxxxxxxxxxx>
> ---
>  Documentation/trace/ftrace.txt |   55 +++++++++++++++++----------------------
>  1 files changed, 24 insertions(+), 31 deletions(-)
> 
> diff --git a/Documentation/trace/ftrace.txt b/Documentation/trace/ftrace.txt
> index a39b3c7..3f058ab 100644
> --- a/Documentation/trace/ftrace.txt
> +++ b/Documentation/trace/ftrace.txt
> @@ -85,26 +85,19 @@ of ftrace. Here is a list of some of the key files:
>  	This file holds the output of the trace in a human
>  	readable format (described below).
>  
> -  latency_trace:
> -
> -	This file shows the same trace but the information
> -	is organized more to display possible latencies
> -	in the system (described below).
> -
>    trace_pipe:
>  
>  	The output is the same as the "trace" file but this
>  	file is meant to be streamed with live tracing.
> -	Reads from this file will block until new data
> -	is retrieved. Unlike the "trace" and "latency_trace"
> -	files, this file is a consumer. This means reading
> -	from this file causes sequential reads to display
> -	more current data. Once data is read from this
> -	file, it is consumed, and will not be read
> -	again with a sequential read. The "trace" and
> -	"latency_trace" files are static, and if the
> -	tracer is not adding more data, they will display
> -	the same information every time they are read.
> +	Reads from this file will block until new data is
> +	retrieved.  Unlike the "trace" file, this file is a
> +	consumer. This means reading from this file causes
> +	sequential reads to display more current data. Once
> +	data is read from this file, it is consumed, and
> +	will not be read again with a sequential read. The
> +	"trace" file is static, and if the tracer is not
> +	adding more data,they will display the same
> +	information every time they are read.
>  
>    trace_options:
>  
> @@ -117,10 +110,10 @@ of ftrace. Here is a list of some of the key files:
>  	Some of the tracers record the max latency.
>  	For example, the time interrupts are disabled.
>  	This time is saved in this file. The max trace
> -	will also be stored, and displayed by either
> -	"trace" or "latency_trace".  A new max trace will
> -	only be recorded if the latency is greater than
> -	the value in this file. (in microseconds)
> +	will also be stored, and displayed by "trace".
> +	A new max trace will only be recorded if the
> +	latency is greater than the value in this
> +	file. (in microseconds)
>  
>    buffer_size_kb:
>  
> @@ -209,8 +202,7 @@ Here is the list of current tracers that may be configured.
>  	Traces the areas that disable interrupts and saves
>  	the trace with the longest max latency.
>  	See tracing_max_latency. When a new max is recorded,
> -	it replaces the old trace. It is best to view this
> -	trace via the latency_trace file.
> +	it replaces the old trace.
>  
>    "preemptoff"
>  
> @@ -307,8 +299,8 @@ the lowest priority thread (pid 0).
>  Latency trace format
>  --------------------
>  
> -For traces that display latency times, the latency_trace file
> -gives somewhat more information to see why a latency happened.
> +For traces that display latency times, the trace file gives
> +somewhat more information to see why a latency happened.



Hmm, now that the latency_trace file has disappeared, this sentence
doesn't make sens anymore.
The trace file gives more information about latency than...? :-)

Actually the latency format still exists.
It's toggable through the latency-format trace option:

echo latency-format > trace_options

I guess this documentation should actually not make the latency
format documentation disappear but actually mirror the moving from
a file to an option.


>  Here is a typical trace.
>  
>  # tracer: irqsoff
> @@ -382,7 +374,7 @@ The above is mostly meaningful for kernel developers.
>  
>    time: This differs from the trace file output. The trace file output
>  	includes an absolute timestamp. The timestamp used by the
> -	latency_trace file is relative to the start of the trace.
> +	trace file is relative to the start of the trace.



This is wrong. The timestamp in the trace file is absolute (relative
to the boot).

Please correct it according to the latency-format option.



>    delay: This is just to help catch your eye a bit better. And
>  	 needs to be fixed to be only relative to the same CPU.
> @@ -440,7 +432,8 @@ Here are the available options:
>    sym-addr:
>     bash-4000  [01]  1477.606694: simple_strtoul <c0339346>
>  
> -  verbose - This deals with the latency_trace file.
> +  verbose - This deals with the trace file when it
> +            displays lantecy times.


"latency"

Is it true when latency-format is not selected?

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/