In-Reply-To: <[email protected]>
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.
--
Chuck
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
