lkml.org 
[lkml]   [2008]   [Jul]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] ftrace: document updates
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/


\
 
 \ /
  Last update: 2008-07-14 23:29    [W:0.208 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site