lkml.org 
[lkml]   [2015]   [Jul]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC PATCH perf/core v2 00/16] perf-probe --cache and SDT support
On 2015/07/25 0:52, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jul 24, 2015 at 04:55:19PM +0900, Namhyung Kim escreveu:
>> 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:
>
>>> 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.
>
> I made some comments about enabling it all by default, look below.
>
>> 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?).
>
> Reading this again after writing what is below: my suggestion is to use
> @, see rationale below.
>
>> 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]
>
> I would show what desambiguates them in non verbose mode, i.e., the
> above would be:
>
> $ perf list sdt_foo:bar
>
> sdt_foo:bar:dir1/libfoo1.so [User SDT event]
> sdt_foo:bar:dir2/libfoo1.so [User SDT event]
> sdt_foo:bar:libfoo2.so [User SDT event]
>
> The -v one would should both the full path and the buildid, but this
> is just polishing up the default output a bit to make it more
> informative.

I agree that the short path is useful, but we know only full path
how to make it short? (only show the differences?)

>
> Now what should be the default when one does:
>
> perf record -e sdt_foo:bar
>
> Will it enable all events or bail out and state that multiple
> events with that name matches, requiring a '--all-matches' to really
> apply it to all events with the same name?

OK, but the problem is that the k/uprobe_event doesn't support multiple
probe on one event yet. This means that if we set those 3 events, it will
be translated to "sdt_foo:bar", "sdt_foo:bar_1", and "sdt_foo:bar_2".
So we need to enhance k/uprobe_event too. Note that, if the event-name
clash happens among events with different type of arguments, we can not
bail it out... It is better to warn user if that happened.

> Humm, this probably will not be that common, so perhaps just
> use all matches by default while telling the user that all those places
> were used and if the user wants just one of them, be more precise,
> adding somehow a disambiguator.
>
> That would be something like this:
>
> perf record -e sdt_foo:bar:0x1234
>
> Or perhaps:
>
> perf record -e sdt_foo:bar@0x1234
>
> Because in this case the 'at' meaning of '@' makes sense, i.e.
> use the std_foo:bar event at the DSO with a 0x1234 buildid?

Ah, that's nice :) I like '@'.

> Additionally, for people that don't want to mess with buildids
> because its environment is deemed well controlled and this works and is
> unambiguous, looking at the LD_LIBRARY_PATH or equivalent:
>
> perf record -e sdt_foo:bar@libfoo2
>
> Full paths could be used as well.
>>
>> $ 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?
>
> If nothing prevents using @ with the meaning of "event at LOCATION"
> where LOCATION is a buildid (noticed because it starts with 0x) or
> a library name or pathname, then that looks more natural.

BTW, will we show it as "[User SDT event]" instead of "[Tracepoint]"?
In that case, after setting the event, same name event will appear
under tracefs/events/. I guess it conflicts with above SDT event.
e.g.

$ perf list sdt_foo:bar

sdt_foo:bar@dir1/libfoo1.so [User SDT event]
sdt_foo:bar@dir2/libfoo1.so [User SDT event]
sdt_foo:bar@libfoo2.so [User SDT event]

And enables on libfoo2.so

$ perf record -e sdt_foo:bar@libfoo2.so

What the perf list shows
$ perf list sdt_foo:bar

sdt_foo:bar@libfoo2.so [Tracepoint]
sdt_foo:bar@dir1/libfoo1.so [User SDT event]
sdt_foo:bar@dir2/libfoo1.so [User SDT event]

Is this OK? Or, we'll need to distinguish sdt_* from other events.

Thank you,

--
Masami HIRAMATSU
Linux Technology Research Center, System Productivity Research Dept.
Center for Technology Innovation - Systems Engineering
Hitachi, Ltd., Research & Development Group
E-mail: masami.hiramatsu.pt@hitachi.com


\
 
 \ /
  Last update: 2015-07-25 03:01    [W:0.089 / U:0.776 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site