Pekka J Enberg wrote:
On Wed, 26 Apr 2006, Jörn Engel wrote:
Still, if you could respin this with gcc 4.1 and post the numbers,
Pekka, that would be quite interesting.
Inlining kfree the way I did doesn't pay off in 4.1 either.
Not to dispute your conclusions or method, but I think doing a
defconfig or your personal config might be more representative
of % size increase of text that will actually be executed. And
that is the expensive type of text.
eg. core code may contain many more instances of checks that
cannot be optimised away, meaning it may be a more significant
cache footprint increase than the 0.05% increase in your test.
Of course, it is equally possible that the instances in core
code do not represent often-executed code, so it is a bit of a
fudge either way.
text data bss dec hex filename
24910301 6946478 2092332 33949111 20605b7 vmlinux-gcc-3.4.5
24934157 6946530 2092332 33973019 206631b vmlinux-inline-kfree-gcc-3.4.5
24171004 6484710 2090188 32745902 1f3a9ae vmlinux-gcc-4.1.0
24185925 6484722 2090188 32760835 1f3e403 vmlinux-inline-kfree-gcc-4.1.0
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
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]
