Re: Re: Re: [RFC PATCH perf/core v2 00/16] perf-probe --cache and SDT support

[Namhyung Kim <namhyung@kernel.org>]

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.
> 
>  - <provider>:<name>
> 	simple, but could easily clash with others.
>  - probe_<provider>:<name>
>  - sdt_<provider>:<name>
> 	also simple and similar to current solution. but fragile against
> 	clash among SDTs.
>  - probe_<binary>:<provider>_<name>
> 	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.
>  - <provider>_<buildid>/<name>
> 	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