From owner-freebsd-current@FreeBSD.ORG Fri May 6 09:04:55 2011 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8B2EE106564A for ; Fri, 6 May 2011 09:04:55 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id DCC8D8FC19 for ; Fri, 6 May 2011 09:04:54 +0000 (UTC) Received: from outgoing.leidinger.net (p5B1556E7.dip.t-dialin.net [91.21.86.231]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id C5298844010; Fri, 6 May 2011 11:04:40 +0200 (CEST) Received: from webmail.leidinger.net (webmail.Leidinger.net [IPv6:fd73:10c7:2053:1::2:102]) by outgoing.leidinger.net (Postfix) with ESMTP id 0CF27120D; Fri, 6 May 2011 11:04:38 +0200 (CEST) Received: (from www@localhost) by webmail.leidinger.net (8.14.4/8.13.8/Submit) id p4694a1B039941; Fri, 6 May 2011 11:04:36 +0200 (CEST) (envelope-from Alexander@Leidinger.net) Received: from pslux.ec.europa.eu (pslux.ec.europa.eu [158.169.9.14]) by webmail.leidinger.net (Horde Framework) with HTTP; Fri, 06 May 2011 11:04:36 +0200 Message-ID: <20110506110436.167568wcm6sjlt44@webmail.leidinger.net> Date: Fri, 06 May 2011 11:04:36 +0200 From: Alexander Leidinger To: David Christensen References: <5D267A3F22FD854F8F48B3D2B523819360D799A42B@IRVEXCHCCR01.corp.ad.broadcom.com> In-Reply-To: <5D267A3F22FD854F8F48B3D2B523819360D799A42B@IRVEXCHCCR01.corp.ad.broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Dynamic Internet Messaging Program (DIMP) H3 (1.1.6) X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: C5298844010.AFC04 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=0.6, required 6, autolearn=disabled, J_CHICKENPOX_39 0.60) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1305277481.75589@r05LN6H7pcPsYrVCIAaszQ X-EBL-Spam-Status: No Cc: "freebsd-current@freebsd.org" Subject: Re: Using Dtrace for Performance Evaluation X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 May 2011 09:04:55 -0000 Quoting David Christensen (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 > { > > @callouts[((struct callout *)arg0)->c_func] = sum(timestamp - > self->in); > } > > tick-10sec > { > printa("%40a %10@d\n", @callouts); > clear(@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; @calls[probeprov, execname, probefunc] = count(); } linuxulator*:::return /self->time[probefunc] != 0/ { this->timediff = self->time[probefunc] - vtimestamp; @stats[probeprov, execname, probefunc] = quantize(this->timediff); @longest[probeprov, probefunc] = max(this->timediff); self->time[probefunc] = 0; } END { printf("Number of calls per provider/application/kernel function:"); printa(@calls); printf("CPU-timing statistics per provider/application/kernel function (in ns):"); printa(@stats); printf("Longest running (CPU-time!) functions per provider (in ns):"); printa(@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 @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137