What I am looking for is a kernel function like "is_enabled()". This function can tell if DTrace is running or a Probe is enabled.

With this function, my code to implement a DTrace probe would be :

 if ( is_enabled() ) {
    allocate memory for DTrace arguments;
}

 DTRACE_PROBE(...);

In this way, the heavy weight memory allocation function will not be called if DTrace is not enabled.

Regards,

Danhua


On 11/02/08 21:32, Angelo Rajadurai wrote:
My understanding was that the is enabled probe is only available in the userland for USDT probes. What Danhua wants seems to be in the kernel. Not sure this would work.

-Angelo


Nikita Zinoviev wrote:
I do not remember exact details, but we have such functionality in dtrace support for java in JDK 7. I guess, it just looks whether nops are replaced by the breakpoint at the beginning of the probe handler (?). I suggest you ask Keith, [EMAIL PROTECTED] The idea was to give the user ability to skip heavy preprocessing of probe arguments if the probe is not enabled.
As far as I know this solution for C code will be *very* efficient,
(in java it involved context switching, so calling Probe::isEnabled() had nearly the same cost as actually firing the probe).


Hope this helps,

Nikita


Danhua Shao wrote:
Hi,

I am adding DTrace probes within NFS v3 client. In my current implementation, I use some tsd_*() functions and kmem_zalloc() function. These functions might be heavy and affect the performance. I want to call this function only when DTrace is running or the DTrace probes are enable. So is there a way to check DTrace is running or DTrace probe is enabled?

Regards,

Danhua
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org

_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org

Reply via email to