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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 [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]
  Powered by Linux