From: Frederic Weisbecker <fweisbec@gmail.com>
To: Zhaolei <zhaolei@cn.fujitsu.com>
Cc: Ingo Molnar <mingo@elte.hu>, Steven Rostedt <rostedt@goodmis.org>,
Tom Zanussi <tzanussi@gmail.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v3 1/2] ftrace: Add task_comm support for trace_event
Date: Tue, 26 May 2009 02:44:52 +0200 [thread overview]
Message-ID: <20090526004451.GF7879@nowhere> (raw)
In-Reply-To: <4A1A6EEF.2090902@cn.fujitsu.com>
On Mon, May 25, 2009 at 06:11:59PM +0800, Zhaolei wrote:
> If we use trace_event alone(without function trace, .etc),
> it can't output enough task command information.
>
> Before patch:
> # echo 1 > debugfs/tracing/events/sched/sched_switch/enable
> # cat debugfs/tracing/trace
> # tracer: nop
> #
> # TASK-PID CPU# TIMESTAMP FUNCTION
> # | | | | |
> <...>-2289 [000] 526276.724790: sched_switch: task bash:2289 [120] ==> sshd:2287 [120]
> <...>-2287 [000] 526276.725231: sched_switch: task sshd:2287 [120] ==> bash:2289 [120]
> <...>-2289 [000] 526276.725452: sched_switch: task bash:2289 [120] ==> sshd:2287 [120]
> <...>-2287 [000] 526276.727181: sched_switch: task sshd:2287 [120] ==> swapper:0 [140]
> <idle>-0 [000] 526277.032734: sched_switch: task swapper:0 [140] ==> events/0:5 [115]
> <...>-5 [000] 526277.032782: sched_switch: task events/0:5 [115] ==> swapper:0 [140]
> ...
>
> After patch:
> # tracer: nop
> #
> # TASK-PID CPU# TIMESTAMP FUNCTION
> # | | | | |
> bash-2269 [000] 527347.989229: sched_switch: task bash:2269 [120] ==> sshd:2267 [120]
> sshd-2267 [000] 527347.990960: sched_switch: task sshd:2267 [120] ==> bash:2269 [120]
> bash-2269 [000] 527347.991143: sched_switch: task bash:2269 [120] ==> sshd:2267 [120]
> sshd-2267 [000] 527347.992959: sched_switch: task sshd:2267 [120] ==> swapper:0 [140]
> <idle>-0 [000] 527348.531989: sched_switch: task swapper:0 [140] ==> events/0:5 [115]
> events/0-5 [000] 527348.532115: sched_switch: task events/0:5 [115] ==> swapper:0 [140]
> ...
>
> Signed-off-by: Zhao Lei <zhaolei@cn.fujitsu.com>
> ---
> kernel/trace/Kconfig | 9 +++++++--
> kernel/trace/trace_events.c | 6 ++++++
> 2 files changed, 13 insertions(+), 2 deletions(-)
>
> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> index f61be30..a508b9d 100644
> --- a/kernel/trace/Kconfig
> +++ b/kernel/trace/Kconfig
> @@ -49,6 +49,11 @@ config FTRACE_NMI_ENTER
> default y
>
> config EVENT_TRACING
> + select CONTEXT_SWITCH_TRACER
> + bool
> +
> +config CONTEXT_SWITCH_TRACER
> + select MARKERS
> bool
>
> config TRACING
> @@ -176,10 +181,10 @@ config SCHED_TRACER
> This tracer tracks the latency of the highest priority task
> to be scheduled in, starting from the point it has woken up.
>
> -config CONTEXT_SWITCH_TRACER
> +config ENABLE_CONTEXT_SWITCH_TRACER
> bool "Trace process context switches"
> select TRACING
> - select MARKERS
> + select CONTEXT_SWITCH_TRACER
I didn't like this part at a first glance.
But actually that makes sense.
I don't think it would be that worth to separate the cmdline record
from the sched switch tracer because they are both too tight in essence.
So this new ENABLE_CONTEXT_SWITCH_TRACER seems to me a good way
to solve this problem.
Thanks,
Frederic.
> help
> This tracer gets called from the context switch and records
> all switching of tasks.
> diff --git a/kernel/trace/trace_events.c b/kernel/trace/trace_events.c
> index 9e91c4a..9b246eb 100644
> --- a/kernel/trace/trace_events.c
> +++ b/kernel/trace/trace_events.c
> @@ -85,6 +85,7 @@ static void ftrace_clear_events(void)
>
> if (call->enabled) {
> call->enabled = 0;
> + tracing_stop_cmdline_record();
> call->unregfunc();
> }
> }
> @@ -99,12 +100,14 @@ static void ftrace_event_enable_disable(struct ftrace_event_call *call,
> case 0:
> if (call->enabled) {
> call->enabled = 0;
> + tracing_stop_cmdline_record();
> call->unregfunc();
> }
> break;
> case 1:
> if (!call->enabled) {
> call->enabled = 1;
> + tracing_start_cmdline_record();
> call->regfunc();
> }
> break;
> @@ -1058,6 +1061,7 @@ static void trace_module_remove_events(struct module *mod)
> found = true;
> if (call->enabled) {
> call->enabled = 0;
> + tracing_stop_cmdline_record();
> call->unregfunc();
> }
> if (call->event)
> @@ -1262,11 +1266,13 @@ static __init void event_trace_self_tests(void)
> }
>
> call->enabled = 1;
> + tracing_start_cmdline_record();
> call->regfunc();
>
> event_test_stuff();
>
> call->unregfunc();
> + tracing_stop_cmdline_record();
> call->enabled = 0;
>
> pr_cont("OK\n");
> --
> 1.5.5.3
>
next prev parent reply other threads:[~2009-05-26 0:45 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-21 7:08 [PATCH 1/2] ftrace: Add task_comm support for trace_event Zhaolei
2009-05-21 7:09 ` [PATCH 2/2] ftrace: clean up of using ftrace_event_enable_disable() Zhaolei
2009-05-21 13:16 ` Steven Rostedt
2009-05-21 13:15 ` [PATCH 1/2] ftrace: Add task_comm support for trace_event Steven Rostedt
2009-05-22 8:01 ` Ingo Molnar
2009-05-22 8:25 ` Ingo Molnar
2009-05-22 8:49 ` Zhaolei
2009-05-22 10:03 ` [PATCH v2 0/2] " Zhaolei
2009-05-22 10:05 ` [PATCH v2 1/2] " Zhaolei
2009-05-24 20:42 ` Frederic Weisbecker
2009-05-25 3:54 ` Zhaolei
2009-05-25 8:27 ` Frederic Weisbecker
2009-05-22 10:06 ` [PATCH v2 2/2] ftrace: clean up of using ftrace_event_enable_disable() Zhaolei
2009-05-24 20:46 ` Frederic Weisbecker
2009-05-25 5:34 ` Zhaolei
2009-05-25 8:32 ` Frederic Weisbecker
2009-05-22 11:51 ` [PATCH v2 0/2] ftrace: Add task_comm support for trace_event Ingo Molnar
2009-05-25 8:59 ` Zhaolei
2009-05-25 16:45 ` Frederic Weisbecker
2009-05-25 17:01 ` Frederic Weisbecker
2009-05-25 10:03 ` [PATCH v3 " Zhaolei
2009-05-25 10:11 ` [PATCH v3 1/2] " Zhaolei
2009-05-26 0:44 ` Frederic Weisbecker [this message]
2009-05-25 10:13 ` [PATCH v3 2/2] ftrace: clean up of using ftrace_event_enable_disable() Zhaolei
2009-05-23 15:16 ` [PATCH 1/2] ftrace: Add task_comm support for trace_event Christoph Hellwig
2009-05-23 15:18 ` Christoph Hellwig
2009-05-27 22:34 ` [tip:tracing/core] " tip-bot for Zhaolei
2009-05-27 22:35 ` [tip:tracing/core] ftrace: clean up of using ftrace_event_enable_disable() tip-bot for Zhaolei
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090526004451.GF7879@nowhere \
--to=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=tzanussi@gmail.com \
--cc=zhaolei@cn.fujitsu.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.