Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753393AbbGXII7 (ORCPT ); Fri, 24 Jul 2015 04:08:59 -0400 Received: from mail-pd0-f179.google.com ([209.85.192.179]:34291 "EHLO mail-pd0-f179.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751849AbbGXIIr (ORCPT ); Fri, 24 Jul 2015 04:08:47 -0400 Date: Fri, 24 Jul 2015 16:55:19 +0900 From: Namhyung Kim To: Masami Hiramatsu Cc: Arnaldo Carvalho de Melo , Hemant Kumar , Peter Zijlstra , linux-kernel@vger.kernel.org, Adrian Hunter , Ingo Molnar , Jiri Olsa , Borislav Petkov Subject: Re: Re: Re: [RFC PATCH perf/core v2 00/16] perf-probe --cache and SDT support Message-ID: <20150724075519.GA19672@sejong> References: <20150715091352.8915.87480.stgit@localhost.localdomain> <55A7215F.40803@linux.vnet.ibm.com> <55A874C6.5030202@hitachi.com> <55AFA4E2.4040801@linux.vnet.ibm.com> <55B0E872.8030206@hitachi.com> <20150723140127.GD3152@kernel.org> <55B11555.9060100@hitachi.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <55B11555.9060100@hitachi.com> User-Agent: Mutt/1.5.23+89 (0255b37be491) (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4881 Lines: 135 Hi Masami and Arnaldo, On Fri, Jul 24, 2015 at 01:24:53AM +0900, Masami Hiramatsu wrote: > On 2015/07/23 23:01, Arnaldo Carvalho de Melo wrote: > > Em Thu, Jul 23, 2015 at 10:13:22PM +0900, Masami Hiramatsu escreveu: > >> # perf list > >> > >> List of pre-defined events (to be used in -e): > >> ... > >> libc:memory_heap_new [Tracepoint event] > > > > Is it like this or is it like [ku]probes where we already have a > > namespace qualifier, i.e.: > > > > [root@zoo ~]# perf probe icmp_rcv > > Added new event: > > probe:icmp_rcv (on icmp_rcv) > > > > You can now use it in all perf tools, such as: > > > > perf record -e probe:icmp_rcv -aR sleep 1 > > > > [root@zoo ~]# > > > > [root@zoo ~]# perf probe /lib64/libc-2.20.so malloc > > Added new events: > > probe_libc:malloc (on malloc in /lib64/libc-2.20.so) > > probe_libc:malloc_1 (on malloc in /lib64/libc-2.20.so) > > probe_libc:malloc_2 (on malloc in /lib64/libc-2.20.so) > > probe_libc:malloc_3 (on malloc in /lib64/libc-2.20.so) > > probe_libc:malloc_4 (on malloc in /lib64/libc-2.20.so) > > probe_libc:malloc_5 (on malloc in /lib64/libc-2.20.so) > > probe_libc:malloc_6 (on malloc in /lib64/libc-2.20.so) > > probe_libc:malloc_7 (on malloc in /lib64/libc-2.20.so) > > probe_libc:malloc_8 (on malloc in /lib64/libc-2.20.so) > > probe_libc:malloc_9 (on malloc in /lib64/libc-2.20.so) > > probe_libc:malloc_10 (on malloc in /lib64/libc-2.20.so) > > probe_libc:malloc_11 (on malloc in /lib64/libc-2.20.so) > > probe_libc:malloc_12 (on malloc in /lib64/libc-2.20.so) > > probe_libc:malloc_13 (on malloc in /lib64/libc-2.20.so) > > probe_libc:malloc_14 (on malloc in /lib64/libc-2.20.so) > > > > You can now use it in all perf tools, such as: > > > > perf record -e probe_libc:malloc_14 -aR sleep 1 > > > > [root@zoo ~]# > > > > "probe" for kernel events, "probe_%s" % DSO basename for userspace > > events. > > > > Why not continue with that and have SDTs use the probe_%s: namespace? > > Sorry if this was already discussed here... > > :) We are discussing about that in another thread, anyway, probe_%s can > solve a little part of the clash of names. > > > > > If there is some ambiguity, that can be resolved by explicitely setting > > a new name, 'perf probe' has provision for that, right? I.e.: > > Yes, but that means we'll have to give new names before using that. > > Actually, SDT has "provider-name", "event-name" and "probe location" (also > have arguments, but not supported). And provider name is not always same > as the binary name. (actually, the application developers can use any > name for it...) > So adding something special prefix or detect clash before using will > be the option. > > The following patterns we've discussed. > > - : > simple, but could easily clash with others. > - probe_: > - sdt_: > also simple and similar to current solution. but fragile against > clash among SDTs. > - probe_:_ > also simple, but if provider or/and name has '_', it is hard to > split the provider and name. and fragile against clash among SDTs too. > - _/ > possible, but ugly since buildid is a random long xdigits(maybe cut up > to 8 or 12 bytes). As I said, we might allow name clashes as they're rare. I don't want to make it complex just for an uncommon case. I think such a duplicate name is fine as long as 'perf list' indicates it and 'perf record' enable them all. If we agreed to extend the event format, I'd like to keep it simple and to make it optional to add more info (separated by colon?). Maybe something like below. Suppose we have 3 SDT events with a same name: /some/where/dir1/libfoo1.so (build-id: 0x1234...) --> foo:bar /some/where/dir2/libfoo1.so (build-id: 0x5678...) --> foo:bar /some/where/dir2/libfoo2.so (build-id: 0xabcd...) --> foo:bar So perf list shows the single name, but also says it has 3 events. $ perf list sdt_foo:bar sdt_foo:bar (total 3 events) [User SDT event] $ perf list -v sdt_foo:bar sdt_foo:bar:libfoo1.so:0x1234... [User SDT event] sdt_foo:bar:libfoo1.so:0x5678... [User SDT event] sdt_foo:bar:libfoo2.so:0xabcd... [User SDT event] Now perf record can accept any of these forms.. # record all 3 events $ perf record -e 'sdt_foo:bar' # record 2 events from libfoo1.so $ perf record -e 'sdt_foo:bar:libfoo1.so' # record only 1 event $ perf record -e 'sdt_foo:bar:libfoo1.so:0x1234...' What do you think? Thanks, Namhyung -- 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/