Date: Tue, 19 May 2015 22:14:53 -0300
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Alexei Starovoitov <ast@plumgrid.com>
Cc: Namhyung Kim <namhyung@kernel.org>, Wang Nan <wangnan0@huawei.com>,
        paulus@samba.org, a.p.zijlstra@chello.nl, mingo@redhat.com,
        jolsa@kernel.org, dsahern@gmail.com, daniel@iogearbox.net,
        brendan.d.gregg@gmail.com, masami.hiramatsu.pt@hitachi.com,
        lizefan@huawei.com, linux-kernel@vger.kernel.org, pi3orama@163.com
Subject: Re: [RFC PATCH v3 00/37] perf tools: introduce 'perf bpf' command to
 load eBPF programs.
Message-ID: <20150520011453.GA32336@kernel.org>
References: <20150518212013.GB13946@kernel.org>
 <555A5D96.2070509@plumgrid.com>
 <20150519134458.GC13946@kernel.org>
 <20150519160448.GD29162@danjae.kornet>
 <20150519164040.GB19921@kernel.org>
 <555BA112.6090505@plumgrid.com>
 <20150519211033.GF19921@kernel.org>
 <555BAE33.5060502@plumgrid.com>
 <20150519220529.GA26111@kernel.org>
 <555BDD15.2050807@plumgrid.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <555BDD15.2050807@plumgrid.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2270
Lines: 52

Em Tue, May 19, 2015 at 06:02:13PM -0700, Alexei Starovoitov escreveu:
> 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.

Thanks! I'll continue tomorrow, reading those examples as well messages
I saw on netdev.

- Arnaldo
 
> 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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/