From owner-cvs-src@FreeBSD.ORG Thu Jun 14 11:16:41 2007 Return-Path: X-Original-To: cvs-src@freebsd.org Delivered-To: cvs-src@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 902A216A46E; Thu, 14 Jun 2007 11:16:41 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail36.syd.optusnet.com.au (mail36.syd.optusnet.com.au [211.29.133.76]) by mx1.freebsd.org (Postfix) with ESMTP id 2893A13C4B8; Thu, 14 Jun 2007 11:16:40 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from besplex.bde.org (c220-239-235-248.carlnfd3.nsw.optusnet.com.au [220.239.235.248]) by mail36.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l5EBGaPI012935 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Jun 2007 21:16:38 +1000 Date: Thu, 14 Jun 2007 21:16:36 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Kip Macy In-Reply-To: Message-ID: <20070614204629.C33664@besplex.bde.org> References: <200706130617.l5D6HncF038605@repoman.freebsd.org> <20070613184656.N25269@delplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: cvs-src@freebsd.org, cvs-all@freebsd.org, src-committers@freebsd.org, Bruce Evans , Bruce Evans Subject: Re: cvs commit: src/sys/libkern mcount.c X-BeenThere: cvs-src@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2007 11:16:41 -0000 On Wed, 13 Jun 2007, Kip Macy wrote: > On 6/13/07, Kip Macy wrote: >> - Original message - >> No. It's unlikely that you even configure profiling. Bruce >> >> ROTFL. In that case what does 'config -pp' do? And why did it print >> something to the effect of "profiling configured" on the console? And >> why did the hang go away when I re-built without '-pp'? >> >> Never mind. I'll just take the time to update the hwpmc support for my >> hardware. "hwpmc" also doesn't cause a 50% slowdown when in use. > > To be more specific, low-resolution profiling works but causes > netserver rx to drop from 9.7Gbps to 4Gbps. I'd like to know why you > thought it was not configured. Profiling (both kernel and userland) is too expensive to configure if you're not using it. I see a slowdown of 50% for "ping -fq localhost" with kernel profiling configured but not even enabled. ttcp with small packets doesn't slow down quite quite as much until profiling is enabled. Then a 50-70% slowdown is normal. There are just too much layering for things to be very fast with profiling or as fast as possible without profiling. However, operations not involving tinygrams are not slowed down too much by profiling. I think the extra function calls for profiling are relatively more expensive (on amd CPUs at least) than they used to be because they disturb pipelining relatively more, perhaps by hitting a CPU resource limit that doesn't show up in simpler benchmarks. One of the problems with gcc's -finstrument-functions feature has a large overhead that keeps getting larger. FreeBSD used to use this because it is more portable than -pg and my -mprofiler-epilogue feature and -mprofiler-epilogue gets broken by most gcc imports. In gcc-3.4, -finstrument functions became unusable since it breaks inlining of all the little static inline functions in the kernel. In gcc-4-2,, these functions are inlined again, but they are still instrumented, and actually instrumenting them is the most expensive part -- it gives a pair of calls to profiling routines for all of the little static functions in the kernel. Instrumentation calls also cost more than -pf -mprofiler-epilogue due to their portablility (same number of calls but 2 parameters to pass for each call). Instrumentation can be turned off using an attribute(()) but I would prefer not to do that. It is a feature to be able to intrument all functions but you usually don't want to instrument the ones that have been inlined for efficiency. Bruce