* David Bryant (david.bry...@quantum.com) wrote:
> On 04/12/12 01:04, Mathieu Desnoyers wrote:
>> * David Bryant (david.bry...@quantum.com) wrote:
>>> Hi all,
>>>
>>> Is it feasible to have an officially supported way of determining if a
>>> tracepoint is currently enabled?
>>>
>>> In my code I would like to test if the tracepoint is enabled, and if it
>>> isn't, avoid doing expensive setup work.
>>>
>>> I've been doing the following:
>>>
>>> if
>>> (__builtin_expect(!!(__tracepoint_sample_component___message.state), 0))
>>> {
>>> /* setup work */
>>> tracepoint(sample_component, message);
>>> /* cleanup work */
>>> }
>>>
>>> But it's weak for two reasons:
>>>
>>> * The 'state' attribute goes true when the tracepoint is enabled, but
>>> stays true after the tracepoint is disabled. It only goes false when
>>> the session is destroyed.
>>> * It uses a private / unofficial API
>>>
>>> What I'd like is an official API that correctly evaluates whether a
>>> tracepoint is enabled or not?
>>>
>>> Is this possible?
>> Something like:
>>
>> tracepoint_cond(provider, name, cond, ...)
>>
>> might do it.
>>
>> Where "cond" would be an expression (could be a statement-expression),
>> e.g.:
>>
>> tracepoint_cond(myprovider, myevent,
>> ({
>> a = something;
>> z = other;
>> a == z;
>> }),
>> a, z);
>>
>> So we could, in addition to perform some setup, also evaluate a
>> condition before calling the tracepoint. The macro might look like
>> (without the '\' at EOL):
>>
>> #define tracepoint_cond(provider, name, cond, ...)
>> do {
>> if (caa_unlikely(__tracepoint_##provider##___##name.state))
>> {
>> if (cond)
>>
>> __tracepoint_cb_##provider##___##name(__VA_ARGS__);
>> }
>> } while (0)
> Hi Mathieu,
>
> Your proposal seems to introduce a way of providing an additional
> condition for whether to trigger the tracepoint, ie, not only would the
> tracepoint need to be enabled but also 'cond' must be satisfied. This is
> cool, but what I want right now is simply a way of determining whether a
> tracepoint is enabled. If it isn't enabled then I won't do the
> setup/cleanup work to prepare the arguments.
>
> I've been consulting __tracepoint_##provider##___##name.state but am
> unsatisfied because it's unofficial API and it isn't quite the right
> test.
Hrm. So what you would like is something like:
int tracepoint_get_state(provider, name);
So you could use it for your setup and cleanup. However, let's see the
possible use of this construct:
1 - this construct would be OK:
if (tracepoint_get_state(myprovider, myname)) {
setup();
tracepoint(myprovider, myname, args...);
cleanup();
}
but we see that the state test would happen twice, which is somewhat
inefficient.
But the actual problem comes from this construct, which is _not_ OK, and
racy:
2 -
if (tracepoint_get_state(myprovider, myname))
setup();
tracepoint(myprovider, myname, args...);
if (tracepoint_get_state(myprovider, myname))
cleanup();
The problem is that users would expect that some synchronization
magically happen when enabling/disabling tracepoints, but it's not the
case. So we could very well end up executing just the cleanup, or just
the tracepoint, or 2 of the 3, if we hit the tracepoint while it is
being enabled/disabled.
Providing this level of deep access into the tracepoint structures seems
error-prone (as shown by construct #2), and inefficient (as shown by the
2 tests performed by construct #1).
This is why I am tempted to introduce a tracepoint_cond() or something
similar, to ensure that no racy construct can be created, and ensure
that we only test the tracepoint state once per site.
Thoughts ?
Thanks,
Mathieu
>
> Thanks,
> Dave
>> So in your case, a statement-expression that evaluates to "true" would
>> be fine.
>>
>> Note that adding support for STAP_PROBEV in there might be a bit less
>> straightforward, because STAP_PROBEV don't depend on the tracepoint
>> state.
>>
>> Thoughts ?
>>
>> Thanks,
>>
>> Mathieu
>>
>>
>>> Thanks,
>>> Dave
>>>
>>> ----------------------------------------------------------------------
>>> The information contained in this transmission may be confidential. Any
>>> disclosure, copying, or further distribution of confidential information is
>>> not permitted unless such privilege is explicitly granted in writing by
>>> Quantum. Quantum reserves the right to have electronic communications,
>>> including email and attachments, sent across its networks filtered through
>>> anti virus and spam software programs and retain such messages in order to
>>> comply with applicable data security and retention requirements. Quantum is
>>> not responsible for the proper and complete transmission of the substance
>>> of this communication or for any delay in its receipt.
>>> _______________________________________________
>>> lttng-dev mailing list
>>> lttng-dev@lists.lttng.org
>>> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>>
>
--
Mathieu Desnoyers
Operating System Efficiency R&D Consultant
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
