Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752598AbbETBCS (ORCPT ); Tue, 19 May 2015 21:02:18 -0400 Received: from mail-pa0-f54.google.com ([209.85.220.54]:33842 "EHLO mail-pa0-f54.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752502AbbETBCP (ORCPT ); Tue, 19 May 2015 21:02:15 -0400 Message-ID: <555BDD15.2050807@plumgrid.com> Date: Tue, 19 May 2015 18:02:13 -0700 From: Alexei Starovoitov User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Arnaldo Carvalho de Melo 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. References: <20150518204416.GJ18563@kernel.org> <555A541F.6090606@plumgrid.com> <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> In-Reply-To: <20150519220529.GA26111@kernel.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2022 Lines: 47 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/