This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH v4 5/5] perf/sdt: Add support to perf record to trace SDT events
- From: Josh Stone <jistone at redhat dot com>
- To: Masami Hiramatsu <masami dot hiramatsu dot pt at hitachi dot com>
- Cc: Namhyung Kim <namhyung at kernel dot org>, Hemant Kumar <hemant at linux dot vnet dot ibm dot com>, linux-kernel at vger dot kernel dot org, srikar at linux dot vnet dot ibm dot com, peterz at infradead dot org, oleg at redhat dot com, hegdevasant at linux dot vnet dot ibm dot com, mingo at redhat dot com, systemtap at sourceware dot org, aravinda at linux dot vnet dot ibm dot com, penberg at iki dot fi, Arnaldo Carvalho de Melo <acme at redhat dot com>
- Date: Wed, 05 Nov 2014 18:15:35 -0800
- Subject: Re: [PATCH v4 5/5] perf/sdt: Add support to perf record to trace SDT events
- Authentication-results: sourceware.org; auth=none
- References: <20141102105006 dot 21708 dot 28734 dot stgit at hemant-fedora> <20141102105557 dot 21708 dot 19032 dot stgit at hemant-fedora> <87lhnr5sbl dot fsf at sejong dot aot dot lge dot com> <54588905 dot 7040002 at linux dot vnet dot ibm dot com> <5458CD15 dot 4010101 at hitachi dot com> <874muew2hk dot fsf at sejong dot aot dot lge dot com> <5459E865 dot 6050207 at hitachi dot com>
On 11/05/2014 01:05 AM, Masami Hiramatsu wrote:
> [Off topic] I really don't like that the current SDT's semaphore. If the user apps
> see the instruction at the probe point, it is easy to check whether the event is
> enabled or not. Thus I recommend to change its implementation and update version
> instead of supporting current semaphore by perftools.
You and I have banged heads on this before, but I don't think checking
the instruction is a simple as you seem to think. I invite you to
prototype this, and if you get it working we can discuss the tradeoffs.
The good news is that other tools (stap and gdb) won't need to care. If
the SDT semaphore goes automatic, then we can just set that note field
to zero, unused from the tool's perspective.
Another tactic is to just discourage developers from using the semaphore
in the first place, as it's a completely optional feature. The marker
is just a NOP, so adding some "if (enabled) {...}" around it is often a
useless load and branch. It does make sense if the probe wants to
provide some expensively-computed arguments though, like cpython does to
prepare a function name string. So if you see a project testing the
semaphore around simple arguments, I'd suggest they just probe directly
instead.
Thanks,
Josh