Re: [PATCH v4 2/3] Support for perf to probe into SDT markers:
From: Pekka Enberg
Date: Mon Oct 28 2013 - 04:48:52 EST
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/