<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/Documentation/trace/ftrace.txt, branch v4.1.22</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>Documentation: Fix the wrong command `echo -1 &gt; set_ftrace_pid` for cleaning the filter.</title>
<updated>2015-02-09T16:04:17+00:00</updated>
<author>
<name>Wang Long</name>
<email>long.wanglong@huawei.com</email>
</author>
<published>2015-02-05T05:16:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=52e68924dfa8d9de5d82f6798352eecc5f03a97d'/>
<id>52e68924dfa8d9de5d82f6798352eecc5f03a97d</id>
<content type='text'>
The command `echo &gt; set_ftrace_pid` should be used to clean the filter quietly.
because the command `echo -1 &gt;  set_ftrace_pid` will output the following:
"bash: echo: write error: Invalid argument".

so update the file Documentation/trace/ftrace.txt.

Signed-off-by: Wang Long &lt;long.wanglong@huawei.com&gt;
Acked-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The command `echo &gt; set_ftrace_pid` should be used to clean the filter quietly.
because the command `echo -1 &gt;  set_ftrace_pid` will output the following:
"bash: echo: write error: Invalid argument".

so update the file Documentation/trace/ftrace.txt.

Signed-off-by: Wang Long &lt;long.wanglong@huawei.com&gt;
Acked-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Signed-off-by: Jonathan Corbet &lt;corbet@lwn.net&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tracing: Add additional marks to signal very large time deltas</title>
<updated>2014-12-03T22:10:13+00:00</updated>
<author>
<name>Byungchul Park</name>
<email>byungchul.park@lge.com</email>
</author>
<published>2014-11-24T00:34:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8e1e1df29d837c589c8b4d7b49864481ff7795b8'/>
<id>8e1e1df29d837c589c8b4d7b49864481ff7795b8</id>
<content type='text'>
Currently, function graph tracer prints "!" or "+" just before
function execution time to signal a function overhead, depending
on the time. And some tracers tracing latency also print "!" or
"+" just after time to signal overhead, depending on the interval
between events. Even it is usually enough to do that, we sometimes
need to signal for bigger execution time than 100 micro seconds.

For example, I used function graph tracer to detect if there is
any case that exit_mm() takes too much time. I did following steps
in /sys/kernel/debug/tracing. It was easier to detect very large
excution time with patched kernel than with original kernel.

$ echo exit_mm &gt; set_graph_function
$ echo function_graph &gt; current_tracer
$ echo &gt; trace
$ cat trace_pipe &gt; $LOGFILE
 ... (do something and terminate logging)
$ grep "\\$" $LOGFILE
 3) $ 22082032 us |                      } /* kernel_map_pages */
 3) $ 22082040 us |                    } /* free_pages_prepare */
 3) $ 22082113 us |                  } /* free_hot_cold_page */
 3) $ 22083455 us |                } /* free_hot_cold_page_list */
 3) $ 22083895 us |              } /* release_pages */
 3) $ 22177873 us |            } /* free_pages_and_swap_cache */
 3) $ 22178929 us |          } /* unmap_single_vma */
 3) $ 22198885 us |        } /* unmap_vmas */
 3) $ 22206949 us |      } /* exit_mmap */
 3) $ 22207659 us |    } /* mmput */
 3) $ 22207793 us |  } /* exit_mm */

And then, it was easy to find out that a schedule-out occured by
sub_preempt_count() within kernel_map_pages().

To detect very large function exection time caused by either problematic
function implementation or scheduling issues, this patch can be useful.

Link: http://lkml.kernel.org/r/1416789259-24038-1-git-send-email-byungchul.park@lge.com

Signed-off-by: Byungchul Park &lt;byungchul.park@lge.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Currently, function graph tracer prints "!" or "+" just before
function execution time to signal a function overhead, depending
on the time. And some tracers tracing latency also print "!" or
"+" just after time to signal overhead, depending on the interval
between events. Even it is usually enough to do that, we sometimes
need to signal for bigger execution time than 100 micro seconds.

For example, I used function graph tracer to detect if there is
any case that exit_mm() takes too much time. I did following steps
in /sys/kernel/debug/tracing. It was easier to detect very large
excution time with patched kernel than with original kernel.

$ echo exit_mm &gt; set_graph_function
$ echo function_graph &gt; current_tracer
$ echo &gt; trace
$ cat trace_pipe &gt; $LOGFILE
 ... (do something and terminate logging)
$ grep "\\$" $LOGFILE
 3) $ 22082032 us |                      } /* kernel_map_pages */
 3) $ 22082040 us |                    } /* free_pages_prepare */
 3) $ 22082113 us |                  } /* free_hot_cold_page */
 3) $ 22083455 us |                } /* free_hot_cold_page_list */
 3) $ 22083895 us |              } /* release_pages */
 3) $ 22177873 us |            } /* free_pages_and_swap_cache */
 3) $ 22178929 us |          } /* unmap_single_vma */
 3) $ 22198885 us |        } /* unmap_vmas */
 3) $ 22206949 us |      } /* exit_mmap */
 3) $ 22207659 us |    } /* mmput */
 3) $ 22207793 us |  } /* exit_mm */

And then, it was easy to find out that a schedule-out occured by
sub_preempt_count() within kernel_map_pages().

To detect very large function exection time caused by either problematic
function implementation or scheduling issues, this patch can be useful.

Link: http://lkml.kernel.org/r/1416789259-24038-1-git-send-email-byungchul.park@lge.com

Signed-off-by: Byungchul Park &lt;byungchul.park@lge.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ftrace, kprobes: Support IPMODIFY flag to find IP modify conflict</title>
<updated>2014-11-21T19:42:10+00:00</updated>
<author>
<name>Masami Hiramatsu</name>
<email>masami.hiramatsu.pt@hitachi.com</email>
</author>
<published>2014-11-21T10:25:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=f8b8be8a310a55856fd2c369dade08088d85df3b'/>
<id>f8b8be8a310a55856fd2c369dade08088d85df3b</id>
<content type='text'>
Introduce FTRACE_OPS_FL_IPMODIFY to avoid conflict among
ftrace users who may modify regs-&gt;ip to change the execution
path. If two or more users modify the regs-&gt;ip on the same
function entry, one of them will be broken. So they must add
IPMODIFY flag and make sure that ftrace_set_filter_ip() succeeds.

Note that ftrace doesn't allow ftrace_ops which has IPMODIFY
flag to have notrace hash, and the ftrace_ops must have a
filter hash (so that the ftrace_ops can hook only specific
entries), because it strongly depends on the address and
must be allowed for only few selected functions.

Link: http://lkml.kernel.org/r/20141121102516.11844.27829.stgit@localhost.localdomain

Cc: Jiri Kosina &lt;jkosina@suse.cz&gt;
Cc: Seth Jennings &lt;sjenning@redhat.com&gt;
Cc: Petr Mladek &lt;pmladek@suse.cz&gt;
Cc: Vojtech Pavlik &lt;vojtech@suse.cz&gt;
Cc: Miroslav Benes &lt;mbenes@suse.cz&gt;
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Ananth N Mavinakayanahalli &lt;ananth@in.ibm.com&gt;
Cc: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Signed-off-by: Masami Hiramatsu &lt;masami.hiramatsu.pt@hitachi.com&gt;
[ fixed up some of the comments ]
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Introduce FTRACE_OPS_FL_IPMODIFY to avoid conflict among
ftrace users who may modify regs-&gt;ip to change the execution
path. If two or more users modify the regs-&gt;ip on the same
function entry, one of them will be broken. So they must add
IPMODIFY flag and make sure that ftrace_set_filter_ip() succeeds.

Note that ftrace doesn't allow ftrace_ops which has IPMODIFY
flag to have notrace hash, and the ftrace_ops must have a
filter hash (so that the ftrace_ops can hook only specific
entries), because it strongly depends on the address and
must be allowed for only few selected functions.

Link: http://lkml.kernel.org/r/20141121102516.11844.27829.stgit@localhost.localdomain

Cc: Jiri Kosina &lt;jkosina@suse.cz&gt;
Cc: Seth Jennings &lt;sjenning@redhat.com&gt;
Cc: Petr Mladek &lt;pmladek@suse.cz&gt;
Cc: Vojtech Pavlik &lt;vojtech@suse.cz&gt;
Cc: Miroslav Benes &lt;mbenes@suse.cz&gt;
Cc: Ingo Molnar &lt;mingo@kernel.org&gt;
Cc: Ananth N Mavinakayanahalli &lt;ananth@in.ibm.com&gt;
Cc: Josh Poimboeuf &lt;jpoimboe@redhat.com&gt;
Cc: Namhyung Kim &lt;namhyung@kernel.org&gt;
Signed-off-by: Masami Hiramatsu &lt;masami.hiramatsu.pt@hitachi.com&gt;
[ fixed up some of the comments ]
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>sched: Transform resched_task() into resched_curr()</title>
<updated>2014-07-16T11:38:19+00:00</updated>
<author>
<name>Kirill Tkhai</name>
<email>tkhai@yandex.ru</email>
</author>
<published>2014-06-28T20:03:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8875125efe8402c4d84b08291e68f1281baba8e2'/>
<id>8875125efe8402c4d84b08291e68f1281baba8e2</id>
<content type='text'>
We always use resched_task() with rq-&gt;curr argument.
It's not possible to reschedule any task but rq's current.

The patch introduces resched_curr(struct rq *) to
replace all of the repeating patterns. The main aim
is cleanup, but there is a little size profit too:

  (before)
	$ size kernel/sched/built-in.o
	   text	   data	    bss	    dec	    hex	filename
	155274	  16445	   7042	 178761	  2ba49	kernel/sched/built-in.o

	$ size vmlinux
	   text	   data	    bss	    dec	    hex	filename
	7411490	1178376	 991232	9581098	 92322a	vmlinux

  (after)
	$ size kernel/sched/built-in.o
	   text	   data	    bss	    dec	    hex	filename
	155130	  16445	   7042	 178617	  2b9b9	kernel/sched/built-in.o

	$ size vmlinux
	   text	   data	    bss	    dec	    hex	filename
	7411362	1178376	 991232	9580970	 9231aa	vmlinux

	I was choosing between resched_curr() and resched_rq(),
	and the first name looks better for me.

A little lie in Documentation/trace/ftrace.txt. I have not
actually collected the tracing again. With a hope the patch
won't make execution times much worse :)

Signed-off-by: Kirill Tkhai &lt;tkhai@yandex.ru&gt;
Signed-off-by: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Link: http://lkml.kernel.org/r/20140628200219.1778.18735.stgit@localhost
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
We always use resched_task() with rq-&gt;curr argument.
It's not possible to reschedule any task but rq's current.

The patch introduces resched_curr(struct rq *) to
replace all of the repeating patterns. The main aim
is cleanup, but there is a little size profit too:

  (before)
	$ size kernel/sched/built-in.o
	   text	   data	    bss	    dec	    hex	filename
	155274	  16445	   7042	 178761	  2ba49	kernel/sched/built-in.o

	$ size vmlinux
	   text	   data	    bss	    dec	    hex	filename
	7411490	1178376	 991232	9581098	 92322a	vmlinux

  (after)
	$ size kernel/sched/built-in.o
	   text	   data	    bss	    dec	    hex	filename
	155130	  16445	   7042	 178617	  2b9b9	kernel/sched/built-in.o

	$ size vmlinux
	   text	   data	    bss	    dec	    hex	filename
	7411362	1178376	 991232	9580970	 9231aa	vmlinux

	I was choosing between resched_curr() and resched_rq(),
	and the first name looks better for me.

A little lie in Documentation/trace/ftrace.txt. I have not
actually collected the tracing again. With a hope the patch
won't make execution times much worse :)

Signed-off-by: Kirill Tkhai &lt;tkhai@yandex.ru&gt;
Signed-off-by: Peter Zijlstra &lt;peterz@infradead.org&gt;
Cc: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
Cc: Randy Dunlap &lt;rdunlap@infradead.org&gt;
Cc: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Link: http://lkml.kernel.org/r/20140628200219.1778.18735.stgit@localhost
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tracing: Add funcgraph_tail option to print function name after closing braces</title>
<updated>2014-05-21T03:29:32+00:00</updated>
<author>
<name>Robert Elliott</name>
<email>elliott@hp.com</email>
</author>
<published>2014-05-20T22:10:51+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=607e3a29203633eaec7334f2f58f9653df788a06'/>
<id>607e3a29203633eaec7334f2f58f9653df788a06</id>
<content type='text'>
In the function-graph tracer, add a funcgraph_tail option
to print the function name on all } lines, not just
functions whose first line is no longer in the trace
buffer.

If a function calls other traced functions, its total
time appears on its } line.  This change allows grep
to be used to determine the function for which the
line corresponds.

Update Documentation/trace/ftrace.txt to describe
this new option.

Link: http://lkml.kernel.org/p/20140520221041.8359.6782.stgit@beardog.cce.hp.com

Signed-off-by: Robert Elliott &lt;elliott@hp.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
In the function-graph tracer, add a funcgraph_tail option
to print the function name on all } lines, not just
functions whose first line is no longer in the trace
buffer.

If a function calls other traced functions, its total
time appears on its } line.  This change allows grep
to be used to determine the function for which the
line corresponds.

Update Documentation/trace/ftrace.txt to describe
this new option.

Link: http://lkml.kernel.org/p/20140520221041.8359.6782.stgit@beardog.cce.hp.com

Signed-off-by: Robert Elliott &lt;elliott@hp.com&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>ftrace, sched: Add TRACE_FLAG_PREEMPT_RESCHED</title>
<updated>2013-11-11T11:43:39+00:00</updated>
<author>
<name>Peter Zijlstra</name>
<email>peterz@infradead.org</email>
</author>
<published>2013-10-04T15:28:26+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=e5137b50a0640009fd63a3e65c14bc6e1be8796a'/>
<id>e5137b50a0640009fd63a3e65c14bc6e1be8796a</id>
<content type='text'>
Since the introduction of PREEMPT_NEED_RESCHED in:

  f27dde8deef3 ("sched: Add NEED_RESCHED to the preempt_count")

we need to be able to look at both TIF_NEED_RESCHED and
PREEMPT_NEED_RESCHED to understand the full preemption behaviour.

Add it to the trace output.

Signed-off-by: Peter Zijlstra &lt;peterz@infradead.org&gt;
Acked-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Cc: Fengguang Wu &lt;fengguang.wu@intel.com&gt;
Cc: Huang Ying &lt;ying.huang@intel.com&gt;
Cc: Yuanhan Liu &lt;yuanhan.liu@linux.intel.com&gt;
Link: http://lkml.kernel.org/r/20131004152826.GP3081@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Since the introduction of PREEMPT_NEED_RESCHED in:

  f27dde8deef3 ("sched: Add NEED_RESCHED to the preempt_count")

we need to be able to look at both TIF_NEED_RESCHED and
PREEMPT_NEED_RESCHED to understand the full preemption behaviour.

Add it to the trace output.

Signed-off-by: Peter Zijlstra &lt;peterz@infradead.org&gt;
Acked-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
Cc: Fengguang Wu &lt;fengguang.wu@intel.com&gt;
Cc: Huang Ying &lt;ying.huang@intel.com&gt;
Cc: Yuanhan Liu &lt;yuanhan.liu@linux.intel.com&gt;
Link: http://lkml.kernel.org/r/20131004152826.GP3081@twins.programming.kicks-ass.net
Signed-off-by: Ingo Molnar &lt;mingo@kernel.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>Documentation: replace strict_strtoul() with kstrtoul()</title>
<updated>2013-08-20T10:56:26+00:00</updated>
<author>
<name>Jingoo Han</name>
<email>jg1.han@samsung.com</email>
</author>
<published>2013-07-31T21:59:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=0ab943bf5624b2cbb63ce4fa870a7ab76bd732f6'/>
<id>0ab943bf5624b2cbb63ce4fa870a7ab76bd732f6</id>
<content type='text'>
The usage of strict_strtoul() is not preferred, because
strict_strtoul() is obsolete. Thus, kstrtoul() should be
used.

Signed-off-by: Jingoo Han &lt;jg1.han@samsung.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The usage of strict_strtoul() is not preferred, because
strict_strtoul() is obsolete. Thus, kstrtoul() should be
used.

Signed-off-by: Jingoo Han &lt;jg1.han@samsung.com&gt;
Signed-off-by: Jiri Kosina &lt;jkosina@suse.cz&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tracing: Add function probe to trigger a ftrace dump of current CPU trace</title>
<updated>2013-06-11T22:38:48+00:00</updated>
<author>
<name>Steven Rostedt (Red Hat)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2013-04-30T23:00:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=90e3c03c3a09a7b176b3fe59d78f5d9755ac8e37'/>
<id>90e3c03c3a09a7b176b3fe59d78f5d9755ac8e37</id>
<content type='text'>
Add the "cpudump" command to have the current CPU ftrace buffer dumped
to console if a function is hit. This is useful when debugging a
tripple fault, where you have an idea of a function that is called
just before the tripple fault occurs, and can tell ftrace to dump its
content out to the console before it continues.

This differs from the "dump" command as it only dumps the content of
the ring buffer for the currently executing CPU, and does not show
the contents of the other CPUs.

Format is:

  &lt;function&gt;:cpudump

echo 'bad_address:cpudump' &gt; /debug/tracing/set_ftrace_filter

To remove this:

echo '!bad_address:cpudump' &gt; /debug/tracing/set_ftrace_filter

Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add the "cpudump" command to have the current CPU ftrace buffer dumped
to console if a function is hit. This is useful when debugging a
tripple fault, where you have an idea of a function that is called
just before the tripple fault occurs, and can tell ftrace to dump its
content out to the console before it continues.

This differs from the "dump" command as it only dumps the content of
the ring buffer for the currently executing CPU, and does not show
the contents of the other CPUs.

Format is:

  &lt;function&gt;:cpudump

echo 'bad_address:cpudump' &gt; /debug/tracing/set_ftrace_filter

To remove this:

echo '!bad_address:cpudump' &gt; /debug/tracing/set_ftrace_filter

Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tracing: Add function probe to trigger a ftrace dump to console</title>
<updated>2013-06-11T22:38:46+00:00</updated>
<author>
<name>Steven Rostedt (Red Hat)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2013-04-30T19:46:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=ad71d889b88055e61e3970a6744a271a51a94f42'/>
<id>ad71d889b88055e61e3970a6744a271a51a94f42</id>
<content type='text'>
Add the "dump" command to have the ftrace buffer dumped to console if
a function is hit. This is useful when debugging a tripple fault,
where you have an idea of a function that is called just before the
tripple fault occurs, and can tell ftrace to dump its content out
to the console before it continues.

Format is:

  &lt;function&gt;:dump

echo 'bad_address:dump' &gt; /debug/tracing/set_ftrace_filter

To remove this:

echo '!bad_address:dump' &gt; /debug/tracing/set_ftrace_filter

Requested-by: Luis Claudio R. Goncalves &lt;lclaudio@uudg.org&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
Add the "dump" command to have the ftrace buffer dumped to console if
a function is hit. This is useful when debugging a tripple fault,
where you have an idea of a function that is called just before the
tripple fault occurs, and can tell ftrace to dump its content out
to the console before it continues.

Format is:

  &lt;function&gt;:dump

echo 'bad_address:dump' &gt; /debug/tracing/set_ftrace_filter

To remove this:

echo '!bad_address:dump' &gt; /debug/tracing/set_ftrace_filter

Requested-by: Luis Claudio R. Goncalves &lt;lclaudio@uudg.org&gt;
Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>tracing: Bring Documentation/trace/ftrace.txt up to date</title>
<updated>2013-03-15T04:36:10+00:00</updated>
<author>
<name>Steven Rostedt (Red Hat)</name>
<email>rostedt@goodmis.org</email>
</author>
<published>2013-03-13T15:05:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=8d016091d10953e00f9d2c0125cc0ddd46c23a6a'/>
<id>8d016091d10953e00f9d2c0125cc0ddd46c23a6a</id>
<content type='text'>
The ftrace.txt document has been suffering from some serious bit rot.

Updated the current content to how things are as of v3.10.
Remove things that no longer exist.
Add documentation about new features:
  per_cpu
  stats
  instances
  stack trace
  etc.

Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
The ftrace.txt document has been suffering from some serious bit rot.

Updated the current content to how things are as of v3.10.
Remove things that no longer exist.
Add documentation about new features:
  per_cpu
  stats
  instances
  stack trace
  etc.

Signed-off-by: Steven Rostedt &lt;rostedt@goodmis.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
