linux-kernel - Re: [RFC/PATCHSET 0/5] perf ftrace: Implement function latency histogram (v1)

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 linux-cve-announce 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]

Message-ID: <Yaoe7YWV0m4RYXnd@kernel.org>
Date:   Fri, 3 Dec 2021 10:43:09 -0300
From:   Arnaldo Carvalho de Melo <acme@...nel.org>
To:     Namhyung Kim <namhyung@...nel.org>
Cc:     Stephane Eranian <eranian@...gle.com>,
        Jiri Olsa <jolsa@...hat.com>, Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Andi Kleen <ak@...ux.intel.com>,
        Ian Rogers <irogers@...gle.com>,
        Song Liu <songliubraving@...com>,
        Changbin Du <changbin.du@...il.com>
Subject: Re: [RFC/PATCHSET 0/5] perf ftrace: Implement function latency
 histogram (v1)

Em Wed, Dec 01, 2021 at 09:21:52AM -0800, Namhyung Kim escreveu:
> On Wed, Dec 1, 2021 at 3:59 AM Arnaldo Carvalho de Melo <acme@...nel.org> wrote:
> > Em Tue, Nov 30, 2021 at 04:36:49PM -0800, Stephane Eranian escreveu:
> > > I am not too fond of the flat option because as we had more bpf tools
> > > like function latency, then we keep extending the list of commands
> > > each with a small span which is different
> > > from what we have right now.

> > I think we should focus on the tool end result, not on how it is
> > implemented, i.e. in this specific "function latency" tool ftrace is
> > used with BPF, but we could perhaps have used some other mechanism.

> Agreed, but I think function latency belongs to function tracing
> conceptually.  So I added it as a subcommand in perf ftrace
> not just because of the implementation.

Fair enough, I think we can go as-is then, whoever finds this overly
long can do:

alias flat="perf ftrace latency"

And go:

flat -p `pidof firefox`

etc.
 
> > I think all these tools should have as much as possible a common set of
> > options, like the targets (cpu, cgroup, pid, tid, etc) so that one can
> > go from different views for those targets by just changing the name of
> > the tool.
 
> Currently, perf ftrace shares the target options with both subcommands.
> Please see common_options in cmd_ftrace().

Sure, but I was alluding to all perf tools, not just 'perf ftrace'
subcommands, i.e. one can go from:

perf ftrace trace --pid `pidof firefox`

to:

perf trace --pid `pidof firefox`

to:

perf stat --pid `pidof firefox`

to:

perf top --pid `pidof firefox`

and get different views of that workload.

Have you thought about userspace function latencies? What tech would you
use for that, since ftrace doesn't cover those?

Would be nice that a single tool could be used to obtain userspace and
kernel space function latencies, just like 'perf probe' can be used for
kernel and userspace, choosing, behind the scenes, kprobes or uprobes.

- Arnaldo