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

[Martin Bligh <mbligh@mbligh.org>]

> I think the only sane solution [that would be endorsed by distributions] 
> is to allow users to reorder function sections runtime (per boot). That 
> is alot faster and more robust (from a production POV) than a full 
> recompilation of the kernel. Recompilation is always risky, it needs too 
> much context, and has too many tool dependencies - and is thus currently 
> untestable. 

<smhuch> - the sound of my eyeballs popping out and splatting against 
the opposite wall.

So ... recompilation is not testable, but boot time reordering of the 
code somehow is? ;-) Yes, I understand the distro toolchain issues, but 
it's still a scary solution ...

Personally, I'd think the sane thing is not to try to optimise by 
workload, but get 80% of the benefit by just reordering on a more 
generalized workload. Doing boot-time reordering for this on non-custom 
kernels just seems terrifying .. it's not that huge a benefit, surely?

> one problem are modules though - they could only be reordered within 
> themselves. On an average system which has ~100 modules loaded, the 
> average icache fragmentation is +100*128/2 == 6.4K [with 128 byte L1 
> cachelines], which can be significant (depending on the workload). OTOH, 
> modules do have strong internal cohesion - they contain functions that 
> belong together conceptually. So by reordering functions within modules 
> we'll likely be able to realize most of the icache savings possible. The 
> only exception would be workloads that utilize many modules at a high 
> frequency. Such workloads will likely trash the icache anyway.

I was thinking about that with modules earlier, and whether modular 
kernels would actually be faster because of that than a statically 
compiled one. But don't you get similar effects from the .o groupings by 
file we get? or does the linker not preserve those groupings?

M.
-
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/