From owner-svn-src-all@FreeBSD.ORG Tue Dec 20 00:12:05 2011 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 069471065676; Tue, 20 Dec 2011 00:12:05 +0000 (UTC) (envelope-from sgk@troutmask.apl.washington.edu) Received: from troutmask.apl.washington.edu (troutmask.apl.washington.edu [128.95.76.21]) by mx1.freebsd.org (Postfix) with ESMTP id D0B1A8FC08; Tue, 20 Dec 2011 00:12:04 +0000 (UTC) Received: from troutmask.apl.washington.edu (localhost.apl.washington.edu [127.0.0.1]) by troutmask.apl.washington.edu (8.14.5/8.14.5) with ESMTP id pBK0C081051852; Mon, 19 Dec 2011 16:12:00 -0800 (PST) (envelope-from sgk@troutmask.apl.washington.edu) Received: (from sgk@localhost) by troutmask.apl.washington.edu (8.14.5/8.14.5/Submit) id pBK0BxQG051851; Mon, 19 Dec 2011 16:11:59 -0800 (PST) (envelope-from sgk) Date: Mon, 19 Dec 2011 16:11:59 -0800 From: Steve Kargl To: Brooks Davis Message-ID: <20111220001159.GA50555@troutmask.apl.washington.edu> References: <201111291946.pATJkHMs064094@svn.freebsd.org> <4ED544E1.3050307@t-hosting.hu> <4ED545A9.8000304@FreeBSD.org> <0CAA5754-4FAC-4B87-92B7-439B109473C0@bsdimp.com> <20111219204129.GA34783@troutmask.apl.washington.edu> <20111219230443.GB66858@lor.one-eyed-alien.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111219230443.GB66858@lor.one-eyed-alien.net> User-Agent: Mutt/1.4.2.3i X-Mailman-Approved-At: Tue, 20 Dec 2011 01:30:57 +0000 Cc: Doug Barton , Garrett Cooper , Max Khon , svn-src-all@FreeBSD.org, David Chisnall , src-committers@FreeBSD.org, G?bor K?vesd?n , svn-src-head@FreeBSD.org, Warner Losh Subject: Re: svn commit: r228143 - in head: . share/mk tools/build/options X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Dec 2011 00:12:05 -0000 On Mon, Dec 19, 2011 at 05:04:43PM -0600, Brooks Davis wrote: > On Mon, Dec 19, 2011 at 12:41:29PM -0800, Steve Kargl wrote: > > On Mon, Dec 19, 2011 at 08:09:32PM +0000, David Chisnall wrote: > > > On 19 Dec 2011, at 19:52, Warner Losh wrote: > > > > > > > -1. The needs of the many? Please. Let's break a useful feature because some people don't understand it and are impatient? That's lame. > > > > > > How useful is gprof-based profiling these days? Now that we > > > have the DTrace pid provider, don't we have access to much more > > > fine-grained profiling information without the need for shipping > > > two versions of every library? > > > > It is quite uesful given that for the last 20 or so years, > > I can do > > > > cc -o z -pg a.c -lm_p > > ./z > > gprof -b -l ./z z.gmon | more > > > > % cumulative self self total > > time seconds seconds calls ms/call ms/call name > > 72.1 0.91 0.91 0 100.00% _mcount [1] > > 11.1 1.05 0.14 8388608 0.00 0.00 sinf [4] > > 8.2 1.16 0.10 8388608 0.00 0.00 nextafterf [5] > > 4.6 1.21 0.06 0 100.00% .mcount (9) > > > > to ge the information I want. > > I'd tend to agree that we should leave it on at least in HEAD. I think it should be the default on all branches. It adds about 28 MB to /usr/lib and 10 minutes to buildworld on my x86_64 systems, ie., it is in the noise. > > dtrace(1M) does not seem to contain an example that gives the > > equivalent information. In fact, the manpage contains no examples, > > only the statement: > > > > See the Solaris Dynamic Tracing Guide for detailed examples > > of how to use the dtrace utility to perform these tasks. > > > > which, of course, is not very useful given that I do not have a > > Solaris Dynamic Tracing Guide. > > http://docs.oracle.com/cd/E19253-01/817-6223/ is it and the first hit in > google... > Which isn't very useful if the system that I'm working on has no or very limit internet access. A quick scan of Ch. 19, 'profile Provider' does not give anything that looks remotely similar to the above 3 command lines. Ch. 33 'User Process Tracing' isn't any better. Telling a users that getting an execution profile for her code can be done by first learning the D programming language and then reading a 41 Chapter document available on the web isn't too user friendly. And, if I read Chapter 26 of the FreeBSD Handbook correctly: 1) dtrace is experimental 2) one needs to build a kernel with the KDTRACE_HOOKS, DDB_CTF, and possibly KDTRACE_FRAME. 3) one needs to 'kldload dtraceall' module, which is a showstopper for anyone who builds his kernel with 'makeoptions NO_MODULES' -- Steve