lists.openwall.net   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 <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