Re: [PATCH v4 2/3] Support for perf to probe into SDT markers:
From: Namhyung Kim
Date: Tue Oct 29 2013 - 01:50:21 EST
On Sat, 26 Oct 2013 11:50:23 +0200, Ingo Molnar wrote:
> * Srikar Dronamraju <srikar@xxxxxxxxxxxxxxxxxx> wrote:
>> Hi Pekka,
>> > >
>> > > You can now use it in all perf tools, such as:
>> > >
>> > > perf record -e libc:my_event -aR sleep 1
>> > Is there a technical reason why 'perf list' could not show all the
>> > available SDT markers on a system and that the 'market to event'
>> > mapping cannot happen automatically?
>> 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.
> I'd say lets try Pekka's suggestion and make it more palatable if
> there's complaints about the delay. (SSD systems are becoming
> dominant and there the search should be reasonably fast.)
> We could also make 'perf list' more sophisticated, if invoked
> naively as 'perf list' then maybe it should first display the
> various event categories, with a (rough) count:
> $ perf list
> 34 hardware events # use 'perf list --hw' to list them
> 40 hw-cache events # use 'perf list --cache' to list them
> 20 software events # use 'perf list --sw' to list them
> 2 raw events # use 'perf list --raw' to list them
> 120 tracepoints # use 'perf list --tp' to list them
> >10 SDT tracepoints # use 'perf list --sdt' to list them
> # use 'perf list -a' to list all events
> # use 'perf list ./binary' to list events in a given binary
> I.e. bring a bit more structure into it.
I like this. :)
Note that 'perf list' already support this kind of filtering now:
$ perf list hw cache sw tracepoint pmu
$ perf list sched:*
It'd be great if this globbing also supports SDTs.
And for 'perf list ./binary' case, it could detect libraries in the
dependency list and then also scan them.
>> Also if a binary exists in a path thats is not covered in the
>> default search, an user might believe that his binary may not have
>> markers. I know the above reason is more of a user folly than a
>> tooling issue.
> I think in 99% of the usecases people will either use pre-built
> markers that come with their distro, or will be intimately aware of
> the markers because they are in the very app they are developing.
> So I wouldn't worry about 'user has a weird binary' case too much.
> I agree with Pekka that making them easily discoverable and visible
> as a coherent whole is really important.
Agreed. We do need to improve the user experience of the perf tools!
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/