This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH v4 2/3] Support for perf to probe into SDT markers:
- From: Ingo Molnar <mingo at kernel dot org>
- To: Srikar Dronamraju <srikar at linux dot vnet dot ibm dot com>
- Cc: Pekka Enberg <penberg at kernel dot org>, Hemant Kumar <hkshaw at linux dot vnet dot ibm dot com>, LKML <linux-kernel at vger dot kernel dot org>, Peter Zijlstra <peterz at infradead dot org>, Oleg Nesterov <oleg at redhat dot com>, hegdevasant at linux dot vnet dot ibm dot com, Ingo Molnar <mingo at redhat dot com>, anton at redhat dot com, systemtap at sourceware dot org, Namhyung Kim <namhyung at kernel dot org>, Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>, aravinda at linux dot vnet dot ibm dot com
- Date: Sat, 26 Oct 2013 11:50:23 +0200
- Subject: Re: [PATCH v4 2/3] Support for perf to probe into SDT markers:
- Authentication-results: sourceware.org; auth=none
- References: <20131023044511 dot 1886 dot 82571 dot stgit at hemant-fedora> <20131023050502 dot 1886 dot 15779 dot stgit at hemant-fedora> <CAOJsxLFKm3TxeTmGjbpr1r4sZ8fHcM481-5BM_Cq0J8hhtvBqQ at mail dot gmail dot com> <20131025125921 dot GA29424 at linux dot vnet dot ibm dot com>
* Srikar Dronamraju <srikar@linux.vnet.ibm.com> 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.
> 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.
Thanks,
Ingo