dtrace discuss - Nov 2005 - profile-n and tick

Hi:

profile-n and tick specify the interval for firing
probe action handling.  However, the first event
fired is counted after dtrace consumer is invoked.

is there any way to have the first event fired right
after the dtrace consumer invoked. for instance, if
dtrace consumer is invoked with specified D below

profile-1hour {
      printf("%s",xxxxx);
}

It will have printf right after invokation and printf to
std out. the next event starts to fired as 1 hour interval.

Thanks
This message posted from opensolaris.org

On Tue, Nov 08, 2005 at 08:53:53PM -0800, ttoulliu2002
wrote:
> Hi:
> 
> profile-n and tick specify the interval for firing
> probe action handling.  However, the first event
> fired is counted after dtrace consumer is invoked.
> 
> is there any way to have the first event fired right
> after the dtrace consumer invoked. for instance, if
> dtrace consumer is invoked with specified D below
> 
> profile-1hour {
>       printf("%s",xxxxx);
> }
> 
> It will have printf right after invokation and printf to
> std out. the next event starts to fired as 1 hour interval.
> 
BEGIN, profile-1hour {
      printf("%s",xxxxx);
}

should do the trick, but there isn''t actually any guarantee that the
first
firing will be in an hour, unless there are no other dtrace consumers
active.

Cheers,
- jonathan

-- 
Jonathan Adams, Solaris Kernel Development

Hi:

Now I am using this->initCall 

profile:::profile-1sec
/this->initCall/

profile:::profile-1hour
/!this->initCall/

I have to enable probe twice, any better way ?

Thanks
This message posted from opensolaris.org

ttoulliu2002 writes:
 > Hi:
 > 
 > Now I am using this->initCall 
 > 
 > profile:::profile-1sec
 > /this->initCall/
 > 
 > profile:::profile-1hour
 > /!this->initCall/
 > 
 > I have to enable probe twice, any better way ?
 > 
 > Thanks
 > This message posted from opensolaris.org
 > _______________________________________________
 > dtrace-discuss mailing list
 > dtrace-discuss at opensolaris.org


One of the principle of dtrace is that the amount of traced
data per enabling be a set amount. So, we''d need to see what''s
being traced to better answer the question. Sometimes it''s
possible to collapse 2 such enablings using some other
constructs if the structure of the traced data is the same.

-r

On Tue, Nov 08, 2005 at 11:09:18PM -0800, ttoulliu2002
wrote:
> Hi:
> 
> Now I am using this->initCall 
> 
> profile:::profile-1sec
> /this->initCall/
> 
> profile:::profile-1hour
> /!this->initCall/
> 
> I have to enable probe twice, any better way ?
This is not necessary, and will not, in fact, work reliably;  this->
variables
are only valid for a single probe firing.  You should use:

BEGIN, profile:::profile-1hour {

}

That will generally do what you want (the BEGIN probe fires immediately after
all probes have been set up and enabled)

The effect I was discussing was about profile-1hour;  if someone else is
already using that probe, than the first firing will be early (i.e. less
than an hour).  It''s a common gotcha with the profile provider.

Cheers,
- jonathan

-- 
Jonathan Adams, Solaris Kernel Development

Jonthan:

Thanks for your reply.  I got your advice.

In addition, is it possible to have a single probe clause 

profile:::profile
/initalCall/ - 5sec
/secondCall/ - 10sec
/10thCall/ - 1hour
{
     action here
}

I mean is it possible to have interval specified at predictive level
so that clause can be resued.

Thanks
This message posted from opensolaris.org