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

[Linus Torvalds]

On Thu, 5 Jan 2006, Martin Bligh wrote:
> 
> 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?

Yes, I think "crude" is exactly where we want to start. It's much easier 
to then make it smarter later.

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

Yes. And it's entirely possible that "crude" is perfectly fine even in the 
long run. I suspect this is very much a "5% of the work gets us 80% of the 
benefit", with a _very_ long tail with tons of more work to get very minor 
incremental savings..

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

The cache effects are likely the biggest ones, and no, I don't know how 
much denser it will be in the cache. Especially with a 64-byte one.. 
(although 128 bytes is fairly common too).

There are some situations where we have TLB issues, but those are likely 
cases where we don't care about placement performance anyway (ie they'd
be in situations where you use the page-alloc-debug stuff, which is very 
expensive for _other_ reasons ;)

		Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/