Re: [PATCH v4 2/3] Support for perf to probe into SDT markers:

[Pekka Enberg <penberg@iki.fi>]

Hi David,

On 10/25/2013 06:20 PM, David Ahern wrote:
> On 10/25/13 8:20 AM, Pekka Enberg wrote:
>>> Technically feasible. But then we would have to parse each of the
>>> libraries and executables to list them. Right? I am not sure if such a
>>> delay is acceptable.
>>
>> You could do it at 'perf list' time or even build time and cache it. 
>> And add lazy discovery to 'perf record' and friends.
>
> Instead searching all the known files or building a cache, how about 
> just having an option like: perf list <DSO>. perf-record could still 
> do the probe magic behind the scenes.

We probably should also support that. But I don't see why
'perf list' could not tell me about SDT markers in libraries that
are already installed on my system.

The problem I have with all the command line magic is that
while the tracing mechanisms are awesome, they're nearly
impossible to discover even by a power user such as myself
and you almost certainly forget the exact syntax over time.
It's not as if you're tracing all the time.

I wish people remembed how awesome and simple 'perf stat'
and 'perf record' with 'perf report' were compared to oprofile
when the first versions came out. I think much of the nice
perf features are suffering because we're not paying enough
attention how to make them accessible to users.

The proposed SDT marker feature is a good example of that.
I mean, how on earth would I know about the userspace
probes unless I read LKML and know that such a feature
exists? And why would I want to provide mappings for SDT
markers and perf events if I want to trace 'libc:setjmp'?

So I really hope this SDT effort and the ktap effort at least
make some effort in unifying all the nice functionality that's
simple to use and easy to discover. I really, really would
at the end of the day, just 'perf trace' like I 'perf stat' or
'perf record'.

                 Pekka