From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752287AbbETBPE (ORCPT ); Tue, 19 May 2015 21:15:04 -0400 Received: from mail.kernel.org ([198.145.29.136]:52529 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750901AbbETBO7 (ORCPT ); Tue, 19 May 2015 21:14:59 -0400 Date: Tue, 19 May 2015 22:14:53 -0300 From: Arnaldo Carvalho de Melo To: Alexei Starovoitov Cc: Namhyung Kim , Wang Nan , 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> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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.