Date: Thu, 14 Jun 2007 21:16:36 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Kip Macy <kip.macy@gmail.com> Cc: cvs-src@freebsd.org, cvs-all@freebsd.org, src-committers@freebsd.org, Bruce Evans <bde@freebsd.org>, Bruce Evans <brde@optusnet.com.au> Subject: Re: cvs commit: src/sys/libkern mcount.c Message-ID: <20070614204629.C33664@besplex.bde.org> In-Reply-To: <b1fa29170706131150v115ff216q565b3351180ddc1@mail.gmail.com> References: <200706130617.l5D6HncF038605@repoman.freebsd.org> <b1fa29170706122337y558ca741k273e4babb78c936d@mail.gmail.com> <20070613184656.N25269@delplex.bde.org> <b1fa29170706131014t6a9a3d20t228efbfc17b97483@mail.gmail.com> <b1fa29170706131150v115ff216q565b3351180ddc1@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 13 Jun 2007, Kip Macy wrote: > On 6/13/07, Kip Macy <kip.macy@gmail.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070614204629.C33664>