Skip site navigation (1)Skip section navigation (2)
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>