dtrace discuss - Oct 2008 - Is there any way to check if DTrace is running or a DTrace probe is enabled?

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

mdb''s dtrace* dcmds may be of assistance...

 > ::dtrace_state
             ADDR MINOR             PROC NAME                         FILE
ffffff02d485e280     2 ffffff02b2a45570 dtrace           ffffff02cc672d58



 > ::dcmds ! grep dtr
dtrace                   - print dtrace(1M)-like output
dtrace_aggstat           - print DTrace aggregation hash statistics
dtrace_dynstat           - print DTrace dynamic variable hash statistics
dtrace_errhash           - print DTrace error hash
dtrace_helptrace         - print DTrace helper trace
dtrace_state             - print active DTrace consumers
id2probe                 - translate a dtrace_id_t to a dtrace_probe_t

I''m sure others will be able to give you more interesting stuff, but 
this might be a start...

Nathan.




On 31/10/08 09:28 AM, 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 at opensolaris.org
-- 


//////////////////////////////////////////////////////////////////
// Nathan Kroenert		nathan.kroenert at sun.com		//
// Senior Systems Engineer	Phone:	+61 3 9869 6255         //
// Global Systems Engineering	Fax:	+61 3 9869 6288         //
// Level 7, 476 St. Kilda Road 					//
// Melbourne 3004   Victoria	Australia			//
//////////////////////////////////////////////////////////////////

On Thu, Oct 30, 2008 at 05:28:35PM -0500, 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?
What you really want is kernel-mode IS_ENABLED() probes.  Unfortunately,
those have not been implemented yet.

Cheers,
- jonathan

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, Keith.McGuigan at Sun.COM.
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 at opensolaris.org

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, Keith.McGuigan at Sun.COM.
> 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 at opensolaris.org
>>     
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
>

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, Keith.McGuigan at Sun.COM.
>> 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 at opensolaris.org
>>>     
>>>       
>> _______________________________________________
>> dtrace-discuss mailing list
>> dtrace-discuss at opensolaris.org
>>   
>>     
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
>   
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://mail.opensolaris.org/pipermail/dtrace-discuss/attachments/20081103/6ea8987b/attachment.html>

Hi Danhua,

As has been mentioned. This functionality doesn''t yet exist in the  
kernel. If you post the exact code that you''re working on, we can try  
to suggest some alternatives. At some point, we would like an is- 
enabled equivalent in the kernel.

Adam

On Nov 3, 2008, at 7:36 AM, Danhua Shao wrote:
> 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, Keith.McGuigan at Sun.COM.
>>> 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 at opensolaris.org
>>>>
>>>>
>>> _______________________________________________
>>> dtrace-discuss mailing list
>>> dtrace-discuss at opensolaris.org
>>>
>>>
>> _______________________________________________
>> dtrace-discuss mailing list
>> dtrace-discuss at opensolaris.org
>>
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org

--
Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl

Following are the code I am working on.  Welcome suggestions to make 
improvement or alternative approaches :-)

In this project, I add DTrace probe before and after rfs3call() function 
call to collect useful information. Currently the overhead in my 
implementation comes from tsd_set() and tsd_get() functions. (By the 
way, the overhead from memory allocation has been removed by using local 
variables.). The purpose of using tsd_set() and tsd_get() functions is 
to collect some data from rfscall() function, which is *called* by 
rfs3call().  This introduce overhead to nfs client system when DTrace is 
not enabled. A simple experiment show that, in the worst case, the 
overhead from these two functions is about 2% of the whole rfs3call() 
operation.

Following are my code. Two probes are declared before and after 
rfs3call(). To collect an argument value from rfscall(), which is called 
by rfs3call(), we instrument two pieces of code:

1. add tsd_set() function call nbefore rfs3cll() to set the address to 
store a value from rfscall() functions
{
...
uint32_t  xid = 0;

DTRACE_NFSV3CLIENT_5(op__getattr__request, rnode_t, VTOR(vp), cred_t *, cr,
      uint32_t *, &xid, GETATTR3args *, &args, caddr_t, uts_nodename());

 tsd_set(dtrace_nfsv3client_key,&xid); // instrumented code

  error = rfs3call(VTOMI(vp), NFSPROC3_GETATTR,
      xdr_nfs_fh3, (caddr_t)&args,
      xdr_GETATTR3vres, (caddr_t)&res, cr,
      &douprintf, &res.status, 0, &fi);

  DTRACE_NFSV3CLIENT_5(op__getattr__reply, rnode_t, VTOR(vp), cred_t *, cr,
      uint32_t *, &xid, GETATTR3res*, &res, caddr_t, uts_nodename());
...
}

2. Within rfscll(), (which is called by nfs3call), add tsd_get() 
function call.

rfscall()
{
    ...
    status = CLNT_CALL(client, which, xdrargs, argsp,
          xdrres, resp, wait);

     // instrumented code begin
      uint32_t xid;
      (void) CLNT_CONTROL(client, CLGET_XID, (char *)&xid);

      uint32_t noi_xid;
      noi_xid = htonl(xid);

      uint32_t *pxid;
      pxid  = tsd_get(dtrace_nfsv3client_key);
      if (pxid != NULL){
        *pxid = noi_xid;
      }
     // instrumented code end;
     ....
}

Regards,

Danhua


On 11/04/08 07:52, Adam Leventhal wrote:
> Hi Danhua,
>
> As has been mentioned. This functionality doesn''t yet exist in the
> kernel. If you post the exact code that you''re working on, we can
try
> to suggest some alternatives. At some point, we would like an is- 
> enabled equivalent in the kernel.
>
> Adam
>
>   
> --
> Adam Leventhal, Fishworks                        http://blogs.sun.com/ahl
>
> _______________________________________________
> dtrace-discuss mailing list
> dtrace-discuss at opensolaris.org
>