function ordering (was: Re: [RFC] exit_thread() speedups in x86 process.c)

[Arjan van de Ven <arjan@infradead.org>]

On Sat, 2005-07-02 at 14:56 +0300, Denis Vlasenko wrote:
> On Saturday 02 July 2005 05:57, Chuck Ebbert wrote:
> > On Wed, 22 Jun 2005 at 04:41:47 -0400, cutaway wrote:
> > 
> > > The compilers got tweaked to be able to emit
> > > function code to different text sections and a massive system wide code
> > > triage was undertaken based on "common usage scenario" profiling run data
> > > from the perf analysis group.
> > 
> >   Linux scheduler code is in its own text section already, but
> > that might be for profiling the code instead of for performance.
> > (Look for "__sched" in the source code.)
> > 
> >   The gains may not be as much as you think since on X86 and at least
> > some other archs the entire kernel is in one large page.  Still, it's
> > got to make some kind of sense to put infrequently-used code in its
> > own section just to reduce cache pollution.
> > 
> >   I came up with this
> 
> Nice.
> 
> > but only the "__slow" part really makes sense:


hmm. I wonder if a slightly different approach (based on the __slow)
idea would make sense
1) Use -ffunction-sections option from gcc to put each function in it's
own section
2) Use readprofile/oprofile data to collect an (external to the code)
list of hot/cold functions (we can put a default list in the kernel
source somewhere and allow people to measure their own if they want)
3) Use this list to make a linker script to order the functions

this way we don't need to put a lot of __slow's in the code *and* it's
based on measurements not assumptions, and can be tuned for a specific
situation in addition.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/