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

[Martin Bligh <mbligh@mbligh.org>]

Linus Torvalds wrote:
> 
> On Thu, 5 Jan 2006, Linus Torvalds wrote:
> 
>>That way the "profile data" actually follows the source code, and is thus 
>>actually relevant to an open-source project. Because we do _not_ start 
>>having specially optimized binaries. That's against the whole point of 
>>being open source and trying to get users to get more deeply involved with 
>>the project.
> 
> 
> Btw, having annotations obviously works, although it equally obviously 
> will limit the scope of this kind of profile data. You won't get the same 
> kind of granularity, and you'd only do the annotations for cases that end 
> up being very clear-cut. But having an automated feedback cycle for adding 
> (and removing!) annotations should make it pretty maintainable in the long 
> run, although the initial annotations migh only end up being for really 
> core code.
> 
> There's a few papers around that claim that programmers are often very 
> wrong when they estimate probabilities for different code-paths, and that 
> you absolutely need automation to get it right. I believe them. But the 
> fact that you need automation doesn't automatically mean that you should 
> feed the compiler a profile-data-blob.

Hmm. if you're just going to do it as binary on/off ...is it not pretty 
trivial to do a crude test implementation by booting the kernel, turning
on profiling, running a bunch of different tests, then marking anything
that never appears at all in profiling as rare?

Not saying it's a good long-term approach, but would it not give us 
enough data to know whether the whole approach was worthwhile? I suspect
(on random gut-feel) we never call at over 50% of the functions we have
(an even easier hypothesis to test)

OTOH, do we have that much to gain anyway in kernel space? all we're 
doing is packing stuff down into the same cacheline or not, isn't it?
As we have all pages pinned in memory, does it matter for any reason
beyond that?

M.