Bug 11592 - sdt.h should have a 'disable-semaphores' override option
Summary: sdt.h should have a 'disable-semaphores' override option
Status: RESOLVED FIXED
Alias: None
Product: systemtap
Classification: Unclassified
Component: runtime (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Stan Cox
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-12 13:07 UTC by Frank Ch. Eigler
Modified: 2010-05-28 20:56 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
0001-dtrace.in-Allow-definition-of-STAP_LIGHTWEIGHT_PROBE.patch (1.04 KB, patch)
2010-05-25 13:30 UTC, Colin
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Frank Ch. Eigler 2010-05-12 13:07:45 UTC
See https://bugzilla.gnome.org/show_bug.cgi?id=606044
for a situation where semaphores constitute a performance
regression.  (In this case, argument setup is small compared
to the semaphore value check.)

Unless we can automate per-marker semaphore presence, we should
provide an override capability.  It may need to be nothing larger
than allowing an application .c file to define

#define STAP_NO_SEMAPHORES

which then the dtrace.in-generated script would observe and avoid
defining STAP_HAS_SEMAPHORES.
Comment 1 Alexander Larsson 2010-05-12 15:20:30 UTC
Why doesn't semaphores work like the is-enabled stuff in dtrace:
http://blogs.sun.com/ahl/entry/user_land_tracing_gets_better

Seems like that would be much more useful than automatically enabling it for all
probes. And its dtrace compatible to boot.
Comment 2 Frank Ch. Eigler 2010-05-12 15:24:25 UTC
(In reply to comment #1)
> Why doesn't semaphores work like the is-enabled stuff in dtrace:

Right, that foo_IS_ENABLED() is already supported as is.

> Seems like that would be much more useful than automatically enabling it for all
> probes.

The argument has been that we've encountered cases where sdt.h macros
were called with fairly heavy-weight arguments, but without an
explicit foo_IS_ENABLED() wrapper.  In these cases, it helped.  But now
there is evidence that it also hurts sometimes, so we need to re-evaluate.

Comment 3 Alexander Larsson 2010-05-14 07:20:26 UTC
I don't particularly care if semaphores are automatically enabled for probes or
not, as long as there is a way to enable/disable it. For glib i want to disable
it and do it manually where needed. This should imho be the right approach for
all probe sets, but I realize not everyone need to be as careful about
performance issues as core glib functionallity.
Comment 4 Colin 2010-05-25 13:30:41 UTC
Created attachment 4811 [details]
0001-dtrace.in-Allow-definition-of-STAP_LIGHTWEIGHT_PROBE.patch

Something like this (untested) patch?
Comment 5 Frank Ch. Eigler 2010-05-25 13:35:54 UTC
Or maybe we should flip the default over to no-semaphores, and have
a user specifically request it:

-D STAP_SDT_IMPLICIT_SEMAPHORES

(since they can already use foo_ENABLED() for explicit conditions).
Comment 6 Alexander Larsson 2010-05-25 15:11:37 UTC
I agree with frank. Additionally, thats what dtrace does.
Comment 7 Stan Cox 2010-05-28 20:24:45 UTC
commit: 954b1d89f8
I pretty much did the same thing as #4 except all the macro manipulation is in
sdt.h so a program can be built either way without having to rerun dtrace.
Comment 8 Stan Cox 2010-05-28 20:56:01 UTC
flip the default