From owner-freebsd-current@FreeBSD.ORG Tue Mar 21 18:50:11 2006 Return-Path: X-Original-To: current@freebsd.org Delivered-To: freebsd-current@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B154816A420; Tue, 21 Mar 2006 18:50:11 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) by mx1.FreeBSD.org (Postfix) with ESMTP id DD7D143D49; Tue, 21 Mar 2006 18:50:08 +0000 (GMT) (envelope-from gallatin@cs.duke.edu) Received: from grasshopper.cs.duke.edu (grasshopper.cs.duke.edu [152.3.145.30]) by duke.cs.duke.edu (8.13.4/8.13.4) with ESMTP id k2LIo8CC019680 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Mar 2006 13:50:08 -0500 (EST) Received: (from gallatin@localhost) by grasshopper.cs.duke.edu (8.12.9p2/8.12.9/Submit) id k2LIo3TY061432; Tue, 21 Mar 2006 13:50:03 -0500 (EST) (envelope-from gallatin) From: Andrew Gallatin MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17440.19163.8504.103892@grasshopper.cs.duke.edu> Date: Tue, 21 Mar 2006 13:50:03 -0500 (EST) To: "Joseph Koshy" In-Reply-To: <84dead720603211040h3db11614v31ae5d7d9a0c1a28@mail.gmail.com> References: <20060223143856.O9642@fledge.watson.org> <17405.53911.686306.362353@grasshopper.cs.duke.edu> <84dead720603202346t6fe1e94cve033bf002dffa90a@mail.gmail.com> <17440.17965.497455.777452@grasshopper.cs.duke.edu> <84dead720603211040h3db11614v31ae5d7d9a0c1a28@mail.gmail.com> X-Mailer: VM 6.75 under 21.1 (patch 12) "Channel Islands" XEmacs Lucid Cc: Robert Watson , current@freebsd.org Subject: Re: The sixty second pmc howto 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: Tue, 21 Mar 2006 18:50:11 -0000 Joseph Koshy writes: > > For a few modules, I suppose it is OK. But it makes it hard to > > see the "big picture" when a number of modules are loaded. > > Is there any chance you have enough information to hack > > together a view similar to oprofile's opreport -l? Or > > (even better) opreport -ld > > Can you post what that looks like? Sure: % opreport -l CPU: AMD64 processors, speed 2612.09 MHz (estimated) Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 860000 samples % image name app name symbol name 29056 56.1458 vmlinux vmlinux copy_user_generic_c 2116 4.0888 vmlinux vmlinux schedule 1032 1.9942 vmlinux vmlinux skb_dequeue 846 1.6348 vmlinux vmlinux task_rq_lock 763 1.4744 vmlinux vmlinux __wake_up_common 718 1.3874 vmlinux vmlinux try_to_wake_up 608 1.1749 vmlinux vmlinux resched_task <...> 6 0.0116 forcedeth forcedeth (no symbols) 3 0.0058 libc-2.3.4.so gdmgreeter (no symbols) <...> % opreport -ld CPU: AMD64 processors, speed 2612.09 MHz (estimated) Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit mask of 0x00 (No unit mask) count 860000 vma samples % image name app name symbol name ffffffff801e961a 29056 56.1458 vmlinux vmlinux copy_user_generic_c ffffffff801e961a 5 0.0172 ffffffff801e961c 3 0.0103 ffffffff801e9622 28731 98.8815 ffffffff801e9625 280 0.9637 ffffffff801e9627 33 0.1136 ffffffff801e9629 3 0.0103 ffffffff801e962b 1 0.0034 <.....> 0000000000000000 6 0.0116 forcedeth forcedeth (no symbols) 0000000000000e1c 3 50.0000 0000000000000e4c 1 16.6667 00000000000011a9 2 33.3333 <.....> 0000000000000000 3 0.0058 libc-2.3.4.so gdmgreeter (no symbols) 00000000000689f5 1 33.3333 0000000000068dfe 1 33.3333 0000000000080644 1 33.3333 The cool thing about opreport -ld is that it allows you to narrow things down to a single line of code inside a function. > There is a lot of information in hwpmc's event log, but > gprof(1) is only able to deal with one (object) file at > a time. This restriction is likely to pinch even more > when callgraphs are implemented. Yes.. I wonder if gprof might be too restrictive, and it might be better to re-invent a custom interface like oprofile has, and dcpi had. Drew