dtrace discuss - Aug 2007 - Extremely long creat64 latencies on higly

Thanks Michael.

Here is my (slightly corrected) version of the script, after I''ve done
a bit of investment in the dtrace manual (always knew it''s powerful,
but it''s more than that...).

While it appears to run, and when I tried lowering the limit I started getting
results, I''d appreciate it if you could please explain the actions
attached to the last few probes with the different predicates (the numerous
return probes from creat64).

It looks to me a lot like a conditional program flow (first we calculate the
duration, then we commit() the speculation if duration is > limit and
discard() it otherwise) rather than discrete probes that fire independently. I
read the manual as saying that conditional flow isn''t possible in D,
but I could have been wrong. What guarantees that the last free probes will fire
in order, producing an IF-THEN-ELSE logic? If nothing guarantees that - why does
the script work?

Thanks for your help,
 - Yaniv

#!/usr/sbin/dtrace -Fs

int limit;

dtrace:::BEGIN
{
        limit = 1000000000;
}

syscall::creat64:entry
{
        self->spec = speculation();
        speculate(self->spec);
        self->ts=timestamp;
        self->duration = 0;
}

fbt:::entry,
fbt:::return
/self->spec/
{
        speculate(self->spec);
}

syscall::creat64:return
/self->spec/
{
        speculate(self->spec);
        self->duration = timestamp - self->ts;
}

syscall::creat64:return
/self->duration > limit/
{
        commit(self->spec);
        self->spec = 0;
}

syscall::creat64:return
/self->spec/
{
        discard(self->spec);
        self->spec = 0;
}


--
This message posted from opensolaris.org

On Tue, Aug 21, 2007 at 03:04:35AM -0700, Yaniv Aknin
wrote:
> It looks to me a lot like a conditional program flow (first we
> calculate the duration, then we commit() the speculation if duration is
> limit and discard() it otherwise) rather than discrete probes that
> fire independently. I read the manual as saying that conditional flow
> isn''t possible in D, but I could have been wrong. What guarantees
that
> the last free probes will fire in order, producing an IF-THEN-ELSE
> logic? If nothing guarantees that - why does the script work?
If there are several probe descriptions that match a given probe,
they''ll
fire in the order in which they appear in the script. This allows if-then-else
logic -- and obviates that need for that sort of control flow logic.

Adam

-- 
Adam Leventhal, Solaris Kernel Development       http://blogs.sun.com/ahl

Adam,
     let me see if I hear you correctly, as long
as these have identical probes, they will be executed in
order, facilitating an "if-then-else" statement[1]


w:x:y:z
{
	/* "before the if" code */
}

w:x:y:z
/ (some-predicate) /
{
	/* "then" code */
}

w:x:y:z
/ ! (same-predicate) /
{
	/* "else" code */
}

w:x:y:z
{
	/* "after the if-then-else" code */
}



-Pete.




[1] unless the "then" code modifies the predicate!... :-)













 Leventhal wrote On 08/21/07 10:42 AM,:
> On Tue, Aug 21, 2007 at 03:04:35AM -0700, Yaniv Aknin wrote:
> 
>>It looks to me a lot like a conditional program flow (first we
>>calculate the duration, then we commit() the speculation if duration is
>>limit and discard() it otherwise) rather than discrete probes that
>>fire independently. I read the manual as saying that conditional flow
>>isn''t possible in D, but I could have been wrong. What
guarantees that
>>the last free probes will fire in order, producing an IF-THEN-ELSE
>>logic? If nothing guarantees that - why does the script work?
> 
> 
> If there are several probe descriptions that match a given probe,
they''ll
> fire in the order in which they appear in the script. This allows
if-then-else
> logic -- and obviates that need for that sort of control flow logic.
> 
> Adam
>