[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3F63D994-4AD6-4EDE-899B-4B5D6B416B6D@gmail.com>
Date: Sun, 10 May 2020 13:18:12 -0300
From: Arnaldo Melo <arnaldo.melo@...il.com>
To: Steven Rostedt <rostedt@...dmis.org>,
Changbin Du <changbin.du@...il.com>
CC: Jiri Olsa <jolsa@...hat.com>,
Arnaldo Carvalho de Melo <acme@...nel.org>,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Namhyung Kim <namhyung@...nel.org>,
linux-kernel@...r.kernel.org,
"linux-trace-devel@...r.kernel.org"
<linux-trace-devel@...r.kernel.org>
Subject: Re: [PATCH 00/19] perf: ftrace enhancement
On May 10, 2020 12:23:36 PM GMT-03:00, Steven Rostedt <rostedt@...dmis.org> wrote:
>On Sun, 10 May 2020 23:06:09 +0800
>Changbin Du <changbin.du@...il.com> wrote:
>
>> The perf has basic kernel ftrace support but lack support of most
>tracing
>> options. This serias is target to enhance the perf ftrace
>functionality so
>> that we can make full use of kernel ftrace with only perf.
>>
>> In general, this serias be cataloged into two main changes:
>> 1) Improve usability of existing functions. For example, we don't
>need to type
>> extra option to select the tracer.
>> 2) Add new options to support all other ftrace functions.
>>
>> Here is a glance of all ftrace functions with this serias:
>> * - improved existing options.
>> + - new added options.
>>
>> $ sudo perf ftrace -h
>>
>> Usage: perf ftrace [<options>] [<command>]
>> or: perf ftrace [<options>] -- <command> [<options>]
>>
>> * -a, --all-cpus system-wide collection from all CPUs
>> + -b, --buffer-size <n>
>> size of per cpu buffer in kb
>> -C, --cpu <cpu> list of cpus to monitor
>> + -d, --delay <n> Wait <n> ms before tracing
>> -D, --graph-depth <n>
>> Max depth for function graph tracer
>> * -G, --graph-funcs <func>
>> Set graph filter on given functions (imply
>to use function_graph tracer)
>> -g, --nograph-funcs <func>
>> Set nograph filter on given functions
>(imply to use function_graph tracer)
>> + -L, --list-functions List available functions to filter
>> + -l, --long-info Show process names, PIDs, timestamps,
>irq-info if available
>> -N, --notrace-funcs <func>
>> do not trace given functions
>> + -P, --no-pager Do not use pager
>> -p, --pid <pid> trace on existing process id
>> + -s, --func-stack-trace
>> Show kernel stack trace for function tracer
>> + -t, --tid <tid> trace on existing thread id (exclusive to
>--pid)
>> -T, --trace-funcs <func>
>> trace given functions only
>> + -u, --userstacktrace Show stacktrace of the current user space
>thread
>> -v, --verbose be more verbose
>> + --funcgraph-tail Show function tails comment (function_graph
>only)
>> + --latency-format displays additional information about the
>latency (function_graph only)
>> + --nofuncgraph-irqs
>> Ignore functions that happen inside
>interrupt (function_graph only)
>> + --nosleep-time Measure on-CPU time only (function_graph
>only)
>> + --trace-children Trace children processes
>> + --tracing-thresh <n>
>> Only show functions of which the duration
>is greater than <n>µs
>>
>
>Note, we are working on making more of the trace-cmd functionality into
>libraries. See this work here:
>
>https://lore.kernel.org/r/20191219113502.28964-2-tz.stoyanov@gmail.com
>
>Which introduces a libtracefs, that is to handle all the work needed to
>interact with the tracefs directory. This will also be useful for perf
>to read the event directory without having to open code that work.
>
>I'm all for giving perf the functionality of ftrace, but I would like
>to have it do so with a more generic solution that other tools could
>benefit from as well.
>
I think in time things will fall into place, 'perf ftrace' has potential as a way for perf users to have a familiar interface to ftrace, and that I think it's its raison d'être, in time well go on finding ways to have common code.
Tomorrow I'll go over this patch set,
Thanks,
- Arnaldo
>Thanks!
>
>-- Steve
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
Powered by blists - more mailing lists