Messages in this thread | | | Date | Mon, 28 Oct 2013 10:48:42 +0200 | From | Pekka Enberg <> | Subject | Re: [PATCH v4 2/3] Support for perf to probe into SDT markers: |
| |
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
| |