* Andrew Morton <akpm@linux-foundation.org> wrote:

quoted text
> > the main reason is the sched debugging stuff:
> 
> That would serve to explain the 18% growth on x86_64.  But why did 
> i386 grow by much more: 29%?  I'd be suspecting all the new 64-bit 
> arithmetic.

this is what i see on 32-bit:

    text    data     bss     dec     hex filename
   28732    3905      24   32661    7f95 kernel/sched.o-vanilla
   37986    2538      20   40544    9e60 kernel/sched.o-v18
   31092    2426      20   33538    8302 kernel/sched.o-v18-no_sched_debug

text is larger but data got smaller. While they are not equivalent in 
function, the two almost even out each other (and that's without any of 
the uninlining that is in v19). In fact, there's a 1.5K per CPU percpu 
data size win with CFS, which is not visible in this stat. So on 
dual-core the net cost should already be zero.

quoted text
> The cost on 32-bit appears to be pretty high.  Perhaps a round of 
> uninlining will help.

agreed, i've done one more round of uninlining.

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