[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <555BDD15.2050807@plumgrid.com>
Date: Tue, 19 May 2015 18:02:13 -0700
From: Alexei Starovoitov <ast@...mgrid.com>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
CC: Namhyung Kim <namhyung@...nel.org>, Wang Nan <wangnan0@...wei.com>,
paulus@...ba.org, a.p.zijlstra@...llo.nl, mingo@...hat.com,
jolsa@...nel.org, dsahern@...il.com, daniel@...earbox.net,
brendan.d.gregg@...il.com, masami.hiramatsu.pt@...achi.com,
lizefan@...wei.com, linux-kernel@...r.kernel.org, pi3orama@....com
Subject: Re: [RFC PATCH v3 00/37] perf tools: introduce 'perf bpf' command
to load eBPF programs.
On 5/19/15 3:05 PM, Arnaldo Carvalho de Melo wrote:
>
> Ok, can you point me to this bpf_file.c, an example? So that we can talk
> about the parts of it that would be short circuited when not loading the
> bpf_file.o, etc.
There are different use cases that would fit in different perf commands.
- 1st use case is quick kernel debugging which could be something
similar to: samples/bpf/tracex1_kern.c
where the user would type a little program with some filtering and
printing and will say 'perf script prog.c'
where it would compile (in microseconds), load, hook into kernel
and print stuff to the screen.
If it prints too much, the user will just Ctrl-C, tweak the prog
and repeat.
I'm seeing it as replacement of 'add printk to kernel, recompile,
reboot' cycle.
- 2nd use case is performance analysis of various things where
aggregation is happening in the kernel and data is printed by
user space in human friendly way. There are three main categories
of visualization: histograms, heatmaps, flamegraphs.
The program will collect the data into such structures
and perf will be visualizing them.
Currently tracex2 is an example of histogram, tracex3 - heatmap
and flamegraphs in the works.
- 3rd use case is 'top' like visualization
tracex4 example is trying to demo it.
these are my use cases.
- Wang's use case turned out to be 4th category.
My understanding he wants to write a program that pretty
much sophisticated filter with dependencies across multiple
events in the system and at the end visualize one 'master'
event via 'perf report'.
That's what this patch set is about.
I think 'perf record --event file.o' + 'perf report' fits
Wang's use case quite well.
My 1st use case fits 'perf script file.c' model.
How to fit 2 and 3 into perf is hard to see yet.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists