dtrace discuss - Aug 2005 - Avoiding few functions using pid provider probes

I am using the pid provider to probe mostly all functions to get a timing
snapshot.
However there are few probes which have unrealistically high overhead now the
question is how do I make sure those function probes are not enabled using D
language (like !notthisfunction) in my script.
(Overhead comparison was done between DTrace script and one using
Collector/Analyzer )

Using predicates doesn''t help since it still enables the probes but not
use them.. Enabling the probes itself kills the performance  of the test.

pid$1:::entry
/probefunc!="DarnFunction" &&
probefunc!="DarnFunction2"/
{
self->ts = timestamp;
}
pid$1:::return
/probefunc!="DarnFunction" &&
probefunc!="DarnFunction2" && self->ts/
{
@a[probefunc,"C"] =  count() ;
@b[probefunc,"T"] =  sum(timestamp - self->ts) ;
self->ts = 0;
}

Thanks.
Regards,
Jignesh

Jignesh:

Could you specify a pattern in the function part of the probe name
which excluded those particular functions (or included only the
functions that you wanted to instrument)?

As a trivial example, you could exclude all functions which started
with the letter "D":

    pid$1::[!D]*:entry

-morgan
>I am using the pid provider to probe mostly all functions to get a timing
>snapshot.
>However there are few probes which have unrealistically high overhead now
the
>question is how do I make sure those function probes are not enabled using D
>language (like !notthisfunction) in my script.
>(Overhead comparison was done between DTrace script and one using
>Collector/Analyzer )
>
>Using predicates doesn''t help since it still enables the probes but
not use
>them.. Enabling the probes itself kills the performance  of the test.
>
>pid$1:::entry
>/probefunc!="DarnFunction" &&
probefunc!="DarnFunction2"/
>{
>self->ts = timestamp;
>}
>pid$1:::return
>/probefunc!="DarnFunction" &&
probefunc!="DarnFunction2" && self->ts/
>{
>@a[probefunc,"C"] =  count() ;
>@b[probefunc,"T"] =  sum(timestamp - self->ts) ;
>self->ts = 0;
>}
>
>Thanks.
>Regards,
>Jignesh

Hi Morgan,

Somewhat helpful

that works only if the wild Character is included .. I am trying to avoid 
MemoryContextSwitchTo
& LockBuffer

however if I use
[!MemoryContextSwitchTo] 
it fails
but if I use
[!MemoryContextSwitchTo]* 
it works

Also how do I mention both MemoryContextSwitchTo as well as LockBuffer out
there?



Thanks in advance.
Regards,
Jignesh


----- Original Message -----
From: mh12949 at prd-mail1.West.sun.com
Date: Tuesday, August 23, 2005 2:28 pm
Subject: Re: [dtrace-discuss] Avoiding few functions using pid provider probes
> 
> 
> Jignesh:
> 
> Could you specify a pattern in the function part of the probe name
> which excluded those particular functions (or included only the
> functions that you wanted to instrument)?
> 
> As a trivial example, you could exclude all functions which started
> with the letter "D":
> 
>    pid$1::[!D]*:entry
> 
> -morgan
> 
> >I am using the pid provider to probe mostly all functions to get a 
> timing>snapshot.
> >However there are few probes which have unrealistically high 
> overhead now the
> >question is how do I make sure those function probes are not 
> enabled using D
> >language (like !notthisfunction) in my script.
> >(Overhead comparison was done between DTrace script and one using
> >Collector/Analyzer )
> >
> >Using predicates doesn''t help since it still enables the
probes
> but not use
> >them.. Enabling the probes itself kills the performance  of the test.
> >
> >pid$1:::entry
> >/probefunc!="DarnFunction" &&
probefunc!="DarnFunction2"/
> >{
> >self->ts = timestamp;
> >}
> >pid$1:::return
> >/probefunc!="DarnFunction" &&
probefunc!="DarnFunction2" && self->ts/
> >{
> >@a[probefunc,"C"] =  count() ;
> >@b[probefunc,"T"] =  sum(timestamp - self->ts) ;
> >self->ts = 0;
> >}
> >
> >Thanks.
> >Regards,
> >Jignesh
> 
>

Jignesh:

Trying "[!MemoryContextSwitchTo]" won''t work because that
creates a
regular expression character set which does NOT include any of those
listed characters (rather than excluding that particular string).

Unable to come up with an elegant solution, I will offer the following
ugly, brute-force application of regular expressions.

Consider a pattern which excludes functions starting with "M".  Then
add back in those which start with "M" without a following
"e".  Then
add back in those which start with "Me" but without a following
"m".
Continue as necessary for "oryContextSwitchTo". Repeat for
"LockBuffer".

For example:

 pid$target::[!ML]*:entry,  /* exclude funcs starting with "M" or
"L" */
 pid$target::M[!e]*:entry,  /* add back "M" without following
"e"     */
 pid$target::Me[!m]*:entry, /* add back "Me" without following
"m"    */
 pid$target::Mem[!o]*:entry,/* continue this pattern as necessary     */
 pid$target::L[!o]*:entry,  /* repeat for "LockBuffer"               
*/
 pid$target::Lo[!c]*:entry,
 pid$target::Loc[!k]*:entry 
 {
    self->ts = timestamp; 
 }

When I tried this on a test application, I also specified the "-Z"
switch because several of the patterns did not match any functions.

This entire suggestion is predicated on the assumption that the complexity
of this pattern match is paid during instrumentation time (in order to
avoid run-time costs).  I haven''t actually verified that this is true,
so "buyer beware".

-morgan
>Somewhat helpful
>
>that works only if the wild Character is included .. I am trying to avoid 
>MemoryContextSwitchTo 
>& LockBuffer
>
>however if I use
>[!MemoryContextSwitchTo] 
>it fails
>but if I use
>[!MemoryContextSwitchTo]* 
>it works
>
>Also how do I mention both MemoryContextSwitchTo as well as LockBuffer out
>there?