From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751700AbbE1GKJ (ORCPT ); Thu, 28 May 2015 02:10:09 -0400 Received: from mail-pa0-f44.google.com ([209.85.220.44]:33334 "EHLO mail-pa0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751556AbbE1GKD (ORCPT ); Thu, 28 May 2015 02:10:03 -0400 Date: Wed, 27 May 2015 23:09:58 -0700 From: Alexei Starovoitov To: "Wangnan (F)" Cc: paulus@samba.org, a.p.zijlstra@chello.nl, mingo@redhat.com, acme@kernel.org, namhyung@kernel.org, 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, xiakaixu 00238161 Subject: Re: [RFC PATCH v4 10/29] bpf tools: Collect map definitions from 'maps' section Message-ID: <20150528060957.GA21013@Alexeis-MBP.westell.com> References: <1432704004-171454-1-git-send-email-wangnan0@huawei.com> <1432704004-171454-11-git-send-email-wangnan0@huawei.com> <20150528015307.GE20764@Alexeis-MacBook-Pro.local> <55667758.1070206@huawei.com> <20150528022833.GI20764@Alexeis-MacBook-Pro.local> <556686FE.105@huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <556686FE.105@huawei.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 On Thu, May 28, 2015 at 11:09:50AM +0800, Wangnan (F) wrote: > > However this breaks a law in current design that opening phase doesn't > talk to kernel with sys_bpf() at all. All related staff is done in loading > phase. This principle ensures that in every systems, no matter it support > sys_bpf() or not, can read eBPF object without failure. I see, so you want 'parse elf' and 'create maps + load programs' to be separate phases? Fair enough. Then please add a call to release the information collected from elf after program loading is done. relocations and other things are not needed at that point. > Moreover, we are planning to introduce hardware PMU to eBPF in the way like > maps, > to give eBPF programs the ability to access hardware PMU counter. I haven't that's very interesting. Please share more info when you can :) If I understood it right, you want in-kernel bpf to do aggregation and filtering of pmu counters ? And computing a number of cache misses between two kprobe events? I can see how I can use that to measure not only time taken by syscall, but number of cache misses occurred due to syscall. Sounds very useful!