lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Sun, 10 May 2020 13:18:12 -0300
From:   Arnaldo Melo <>
To:     Steven Rostedt <>,
        Changbin Du <>
CC:     Jiri Olsa <>,
        Arnaldo Carvalho de Melo <>,
        Peter Zijlstra <>,
        Ingo Molnar <>,
        Namhyung Kim <>,,
Subject: Re: [PATCH 00/19] perf: ftrace enhancement

On May 10, 2020 12:23:36 PM GMT-03:00, Steven Rostedt <> wrote:
>On Sun, 10 May 2020 23:06:09 +0800
>Changbin Du <> wrote:
>> The perf has basic kernel ftrace support but lack support of most
>> 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
>>     -T, --trace-funcs <func>
>>                           trace given functions only
>> +   -u, --userstacktrace  Show stacktrace of the current user space
>>     -v, --verbose         be more verbose
>> +       --funcgraph-tail  Show function tails comment (function_graph
>> +       --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
>> +       --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:
>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,


- Arnaldo

>-- Steve

Sent from my Android device with K-9 Mail. Please excuse my brevity.

Powered by blists - more mailing lists