Re: Using Dtrace for Performance Evaluation

From: Alexander Leidinger <Alexander_at_Leidinger.net>
Date: Fri, 06 May 2011 11:04:36 +0200
Quoting David Christensen <davidch_at_broadcom.com> (from Thu, 5 May 2011  
13:08:56 -0700):

> I was looking at using dtrace to help characterize performance
> for the new bxe(4) driver but I'm having problems with the very
> simple task of capturing time spent in a function.  The D script
> I'm using looks like the following:
>
> #pragma D option quiet
>
> fbt:if_bxe::entry
> {
>         self->in = timestamp;
> }
>
> fbt:if_bxe::return
> {
>
>         _at_callouts[((struct callout *)arg0)->c_func] = sum(timestamp -
>             self->in);
> }
>
> tick-10sec
> {
>         printa("%40a %10_at_d\n", _at_callouts);
>         clear(_at_callouts);
>         printf("\n");
> }
>
> BEGIN
> {
>         printf("%40s | %s\n", "function", "nanoseconds per second");
> }

I think there is a more easy way of doing this. I have a script which  
wants to do some statistics too (depends upon local changes, but it's  
about the D code, not the providers used), it does this:
---snip---
#pragma D option dynvarsize=32m

linuxulator*:::entry
{
         self->time[probefunc] = vtimestamp;
         _at_calls[probeprov, execname, probefunc] = count();
}

linuxulator*:::return
/self->time[probefunc] != 0/
{
         this->timediff = self->time[probefunc] - vtimestamp;

         _at_stats[probeprov, execname, probefunc] = quantize(this->timediff);
         _at_longest[probeprov, probefunc] = max(this->timediff);

         self->time[probefunc] = 0;
}

END
{
         printf("Number of calls per provider/application/kernel function:");
         printa(_at_calls);
         printf("CPU-timing statistics per provider/application/kernel  
function (in ns):");
         printa(_at_stats);
         printf("Longest running (CPU-time!) functions per provider (in ns):");
         printa(_at_longest);
}
---snip---

In your case you can forget about probeprov, but the probefunc should  
be more convenient to use than the casting and dereferencing you do.  
The constraint for the return is there to prevent problems in case one  
starts the tracing when a CPU is inbetween entry and return.

Bye,
Alexander.

-- 
There is a multi-legged creature crawling on your shoulder.
		-- Spock, "A Taste of Armageddon", stardate 3193.9

http://www.Leidinger.net    Alexander _at_ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild _at_ FreeBSD.org  : PGP ID = 72077137
Received on Fri May 06 2011 - 07:04:55 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:13 UTC