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

Linus Torvalds
2006-01-05T20:18:22Z

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