* Andrew Morton <[email protected]> wrote:
> > 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.
> 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
-
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]
