From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Taeung Song <treeze.taeung@gmail.com>
Cc: linux-kernel@vger.kernel.org, Jiri Olsa <jolsa@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Peter Zijlstra <peterz@infradead.org>,
Wang Nan <wangnan0@huawei.com>
Subject: Re: [PATCH v2 2/4] perf ftrace: Add ftrace.tracer config option
Date: Tue, 31 Jan 2017 09:46:29 -0300 [thread overview]
Message-ID: <20170131124628.GC4491@kernel.org> (raw)
In-Reply-To: <1485862711-20216-3-git-send-email-treeze.taeung@gmail.com>
Em Tue, Jan 31, 2017 at 08:38:29PM +0900, Taeung Song escreveu:
> Currently perf ftrace command will select 'function_graph' or 'function'.
> So add ftrace.tracer config option to select tracer
The above is confusing, I changed it to:
Currently 'perf ftrace' command allows selecting 'function_graph' or
'function', defaulting to 'function_graph'.
Add the ftrace.tracer config option to select the default tracer:
> # cat ~/.perfconfig
> [ftrace]
> tracer = function
>
> # perf ftrace usleep 123456 | head -10
> <...>-14450 [002] d... 10089.284231: finish_task_switch <-__schedule
> <...>-14450 [002] .... 10089.284232: finish_wait <-pipe_wait
> <...>-14450 [002] .... 10089.284232: mutex_lock <-pipe_wait
> <...>-14450 [002] .... 10089.284232: _cond_resched <-mutex_lock
>
> Cc: Jiri Olsa <jolsa@kernel.org>
> Cc: Namhyung Kim <namhyung@kernel.org>
> Signed-off-by: Taeung Song <treeze.taeung@gmail.com>
> ---
> tools/perf/builtin-ftrace.c | 25 +++++++++++++++++++++++++
> 1 file changed, 25 insertions(+)
>
> diff --git a/tools/perf/builtin-ftrace.c b/tools/perf/builtin-ftrace.c
> index 414444d..00e228f 100644
> --- a/tools/perf/builtin-ftrace.c
> +++ b/tools/perf/builtin-ftrace.c
> @@ -17,6 +17,7 @@
> #include "evlist.h"
> #include "target.h"
> #include "thread_map.h"
> +#include "util/config.h"
>
>
> #define DEFAULT_TRACER "function_graph"
> @@ -198,6 +199,26 @@ static int __cmd_ftrace(struct perf_ftrace *ftrace, int argc, const char **argv)
> return done ? 0 : -1;
> }
>
> +static int perf_ftrace_config(const char *var, const char *value, void *cb)
> +{
> + struct perf_ftrace *ftrace = cb;
> +
> + if (!strcmp(var, "ftrace.tracer")) {
> + if (!strcmp(value, "function_graph"))
> + ftrace->tracer = DEFAULT_TRACER;
> + else if (!strcmp(value, "function"))
> + ftrace->tracer = "function";
> + else {
> + pr_err("Please select function_graph(default)"
> + "or function to use tracer.\n");
> + return -1;
> + }
If you use {} in the else case, use it in the other branch, also I
simplified it to be:
+ if (!strcmp(var, "ftrace.tracer")) {
+ if (!strcmp(value, "function_graph") ||
+ !strcmp(value, "function"))
+ ftrace->tracer = value;
+ else {
+ pr_err("Please select function_graph(default)"
+ "or function to use tracer.\n");
+ return -1;
+ }
As we know item->value will not go away (its a perf_config_item,
allocated and kept in that perf_config_set structure).
Also it doesn't make sense comparing against "function_graph" to set it
to DEFAULT_TRACER, as if we decide to change the DEFAULT_TRACER this
simply breaks.
Also you forgot to test by setting an invalid tracer, I did and noticed
that you forgot to add a space between "(default)" and "or ", please be
more careful with testing.
Also you are silently ignoring any unknown variable in this section, so
if someone has this:
cat ~/.perfconfig
[ftrace]
trace = function
I.e. forgets the 'r', it will keep using the current default,
"function_graph" till the user checks the config and adds that missing
'r'...
I haven't changed this because I think this is so common that we should
instead have a different error return for those config callbacks that
will tell perf_config() to say something like:
"unknown variable %s.%s\n", section_name, variable_name
- Arnaldo
> + return 0;
> + }
> +
> + return 0;
> +}
> +
> int cmd_ftrace(int argc, const char **argv, const char *prefix __maybe_unused)
> {
> int ret;
> @@ -218,6 +239,10 @@ int cmd_ftrace(int argc, const char **argv, const char *prefix __maybe_unused)
> OPT_END()
> };
>
> + ret = perf_config(perf_ftrace_config, &ftrace);
> + if (ret < 0)
> + return -1;
> +
> argc = parse_options(argc, argv, ftrace_options, ftrace_usage,
> PARSE_OPT_STOP_AT_NON_OPTION);
> if (!argc)
> --
> 2.7.4
next prev parent reply other threads:[~2017-01-31 13:09 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-31 11:38 [PATCH v2 0/4] Add ftrace config and refactor several parts Taeung Song
2017-01-31 11:38 ` [PATCH v2 1/4] perf tools: Create for_each_event macro for tracepoints iteration Taeung Song
2017-01-31 12:21 ` Arnaldo Carvalho de Melo
2017-01-31 12:23 ` Arnaldo Carvalho de Melo
2017-01-31 17:32 ` Steven Rostedt
2017-02-01 7:02 ` Taeung Song
2017-02-01 14:43 ` [tip:perf/core] " tip-bot for Taeung Song
2017-01-31 11:38 ` [PATCH v2 2/4] perf ftrace: Add ftrace.tracer config option Taeung Song
2017-01-31 12:46 ` Arnaldo Carvalho de Melo [this message]
2017-01-31 13:15 ` Arnaldo Carvalho de Melo
2017-02-01 7:27 ` Taeung Song
2017-02-01 14:43 ` [tip:perf/core] " tip-bot for Taeung Song
2017-01-31 11:38 ` [PATCH v2 3/4] perf tools: Check NULL after zalloc() and Use zfree() instead of free() in parse-events.c Taeung Song
2017-01-31 13:23 ` Arnaldo Carvalho de Melo
2017-02-01 8:04 ` Taeung Song
2017-01-31 11:38 ` [PATCH v2 4/4] perf tools: Increase index if perf_evsel__new_idx() succeeded Taeung Song
2017-01-31 13:25 ` Arnaldo Carvalho de Melo
2017-02-01 8:04 ` Taeung Song
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=20170131124628.GC4491@kernel.org \
--to=acme@kernel.org \
--cc=jolsa@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@kernel.org \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
--cc=treeze.taeung@gmail.com \
--cc=wangnan0@huawei.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.