linux-trace-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnaldo Melo <arnaldo.melo@gmail.com>
To: Steven Rostedt <rostedt@goodmis.org>,
	Changbin Du <changbin.du@gmail.com>
Cc: Jiri Olsa <jolsa@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Namhyung Kim <namhyung@kernel.org>,
	linux-kernel@vger.kernel.org,
	"linux-trace-devel@vger.kernel.org" 
	<linux-trace-devel@vger.kernel.org>
Subject: Re: [PATCH 00/19] perf: ftrace enhancement
Date: Sun, 10 May 2020 13:18:12 -0300	[thread overview]
Message-ID: <3F63D994-4AD6-4EDE-899B-4B5D6B416B6D@gmail.com> (raw)
In-Reply-To: <20200510112336.444906c1@oasis.local.home>



On May 10, 2020 12:23:36 PM GMT-03:00, Steven Rostedt <rostedt@goodmis.org> wrote:
>On Sun, 10 May 2020 23:06:09 +0800
>Changbin Du <changbin.du@gmail.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.

      reply	other threads:[~2020-05-10 16:18 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20200510150628.16610-1-changbin.du@gmail.com>
2020-05-10 15:23 ` [PATCH 00/19] perf: ftrace enhancement Steven Rostedt
2020-05-10 16:18   ` Arnaldo Melo [this message]

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=3F63D994-4AD6-4EDE-899B-4B5D6B416B6D@gmail.com \
    --to=arnaldo.melo@gmail.com \
    --cc=acme@kernel.org \
    --cc=changbin.du@gmail.com \
    --cc=jolsa@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-trace-devel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).