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

Martin Bligh
2006-01-06T00:07:37Z

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