![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2005-07-03 13:53 [W:0.568 / U:0.040 seconds] ©2003-2008 Jasper Spaans | |||||||||||||