Re: [patch 00/2] improve .text size on gcc 4.0 and newer compilers

[Martin Bligh <mbligh@mbligh.org>]

Chuck Ebbert wrote:
> In-Reply-To: <20060104042822.GA3356@waste.org>
> 
> On Tue, 3 Jan 2006 at 22:28:23 -0600, Matt Mackall wrote:
> 
> 
>>On Tue, Jan 03, 2006 at 03:40:59PM -0800, Martin J. Bligh wrote:
>>
>>
>>>It seems odd to me that we're doing this by second-hand effect on
>>>code size ... the objective of making the code smaller is to make it
>>>run faster, right? So ... howcome there are no benchmark results
>>>for this?
>>
>>Because it's extremely hard to design a benchmark that will show a
>>significant change one way or the other for single kernel functions
>>that doesn't also make said functions unusually cache-hot. And part of
>>the presumed advantage of uninlining is that it leaves icache room for
>>random other code that you're _not_ benchmarking.
> 
> 
> Moving code out-of-line can have some serious drawbacks, too.  For example,
> if you have a 12 byte function that is called frequently, you are pinning
> an additional 52 bytes of code in the L1 cache.  Unless that code is also
> called often you might waste more space than you gain from un-inlining.
> 
> E.g. a look at arch/i386/kernel/apic.c shows a bunch of functions that are
> only there because of CPU hotplug, to handle errors or deal with
> suspend/resume/shutdown.  Such code should be in its own text section.
> 
> And the only way to get meaningful benchmarks so you can figure out where
> to place the code would be to instrument the kernel and then run real-world
> applications.

What would be nice to do is pack all the frequently used code together 
in close proximity. Would probably have much larger effects with 
userspace code, esp where we touch disk (which is more page-size 
granularity), but is probably worth doing with kernel code too (where 
AFAICS we'd only get cacheline granular).

M.