Re: [PATCH] ftrace: document updates

[Randy Dunlap <randy.dunlap@oracle.com>]

On Mon, 14 Jul 2008 16:41:12 -0400 (EDT) Steven Rostedt wrote:

a few more...

> The following updates were recommended by Elias Oltmanns and Randy Dunlap.
> 
> [ updates based on Andrew Morton's comments are still to come. ]
> 
> Signed-off-by: Steven Rostedt <srostedt@redhat.com>
> ---
>  Documentation/ftrace.txt |  134 ++++++++++++++++++++++++-----------------------
>  1 file changed, 71 insertions(+), 63 deletions(-)
> 
> Index: linus.git/Documentation/ftrace.txt
> ===================================================================
> --- linus.git.orig/Documentation/ftrace.txt	2008-07-14 11:22:26.000000000 -0400
> +++ linus.git/Documentation/ftrace.txt	2008-07-14 16:07:13.000000000 -0400
> @@ -2,8 +2,11 @@
>  		========================
> 
>  Copyright 2008 Red Hat Inc.
> -Author: Steven Rostedt <srostedt@redhat.com>
> +   Author:   Steven Rostedt <srostedt@redhat.com>
> +  License:   The GNU Free Documentation License, Version 1.2
> +Reviewers:   Elias Oltmanns and Randy Dunlap
> 
> +Writen for: 2.6.26-rc8 linux-2.6-tip.git tip/tracing/ftrace branch
> 
>  Introduction
>  ------------
> @@ -297,13 +302,13 @@ explains which is which.
> 
>  The above is mostly meaningful for kernel developers.
> 
> -  time: This differs from the trace output where as the trace output
> -	contained a absolute timestamp. This timestamp is relative
> -	to the start of the first entry in the the trace.
> +  time: This differs from the trace file output. The trace file output
> +	included an absolute timestamp. The timestamp used by the

	includes

> +	latency_trace file is relative to the start of the trace.
> 
>    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.
> -	The marks is determined by the difference between this
> +	The marks are determined by the difference between this
>  	current trace and the next trace.
>  	 '!' - greater than preempt_mark_thresh (default 100)
>  	 '+' - greater than 1 microsecond
> @@ -570,21 +575,21 @@ vim:ft=help
> 
> 
>  preemptoff
>  ----------
> 
> -When preemption is disabled we may be able to receive interrupts but
> -the task can not be preempted and a higher priority task must wait
> +When preemption is disabled, we may be able to receive interrupts but
> +the task cannot be preempted and a higher priority task must wait
>  for preemption to be enabled again before it can preempt a lower
>  priority task.
> 
> -The preemptoff tracer traces the places that disables preemption.
> +The preemptoff tracer traces the places that disable preemption.
>  Like the irqsoff, it records the maximum latency that preemption

   Like the irqsoff tracer,

>  was disabled. The control of preemptoff is much like the irqsoff.
> 
> @@ -992,12 +997,15 @@ ksoftirq-7     1d..4   50us : schedule (
> 
>  The interrupt went off while running ksoftirqd. This task runs at
>  SCHED_OTHER. Why didn't we see the 'N' set early? This may be
> -a harmless bug with x86_32 and 4K stacks. The need_reched() function
> -that tests if we need to reschedule looks on the actual stack.
> -Where as the setting of the NEED_RESCHED bit happens on the
> -task's stack. But because we are in a hard interrupt, the test
> -is with the interrupts stack which has that to be false. We don't
> -see the 'N' until we switch back to the task's stack.
> +a harmless bug with x86_32 and 4K stacks. On x86_32 with 4K stacks
> +configured, the interrupt and softirq runs with their own stack.

                                         run

> +Some information is held on the top of the task's stack (need_resched
> +and preempt_count are both stored there). The setting of the NEED_RESCHED
> +bit is done directly to the task's stack, but the reading of the
> +NEED_RESCHED is done by looking at the current stack, which in this case
> +is the stack for the hard interrupt. This hides the fact that NEED_RESCHED
> +has been set. We don't see the 'N' until we switch back to the task's
> +assigned stack.
> 
>  ftrace
>  ------


---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/