From: Kurt Wall <kwall@kurtwerks.com>
To: Mitchell Blank Jr <mitch@sfgoth.com>
Cc: Arjan van de Ven <arjan@infradead.org>,
linux-kernel@vger.kernel.org, akpm@osdl.org
Subject: Re: [patch 7/7] Make "inline" no longer mandatory for gcc 4.x
Date: Sun, 8 Jan 2006 02:14:16 -0500 [thread overview]
Message-ID: <20060108071416.GD26614@kurtwerks.com> (raw)
In-Reply-To: <20060108035622.GP27284@gaz.sfgoth.com>
On Sat, Jan 07, 2006 at 07:56:22PM -0800, Mitchell Blank Jr took 0 lines to write:
> Kurt Wall wrote:
> > text data bss dec hex filename
> > 2577982 462352 479920 3520254 35b6fe vmlinux.344.NO_OPT
> > 2620255 462336 479984 3562575 365c4f vmlinux.442.NO_OPT
> > 2326785 462352 479920 3269057 31e1c1 vmlinux.344.OPT
> > 2227294 502680 479984 3209958 30fae6 vmlinux.442.OPT
>
> And idea what's up with the .data size there? The first three are almost
> exactly the same (as you'd expect) and then the last one jumps up by 40K.
> Is there something normally in a different section that goes into normal
> .data only in that congiguration? Might be worth looking at with:
> objdump -h vmlinux | egrep -v 'CONTENTS|ALLOC'
Given that I don't really understand what I'm looking at in this output,
all this really shows me is that, yes, .data is ~40K larger. I'd think
what we're really interested in is the contents of .data. I don't
read hex as well as I read decimal, so I converted it):
Section 344.OPT 442.OPT Delta
-------------------------------------------
.text 2135463 1783653 -351810
__ex_table 17648 16768 -880
.rodata 239127 217865 -21262
.pci_fixup 2112 2112 0
.rio_route 0 0 0
__ksymtab 34352 34352 0
__ksymtab_gpl 5808 5808 0
__kcrctab 17176 17176 0
__kcrctab_gpl 2904 2904 0
__ksymtab_strings 54818 54818 0
__param 2360 2360 0
.data 386816 427160 40344
.bss 479984 479984 0
.data.cacheline_aligned 16896 16896 0
.data.read_mostly 3104 3104 0
.vsyscall_0 295 255 -40
.xtime_lock 4 4 0
.vxtime 48 48 0
.wall_jiffies 8 8 0
.sys_tz 8 8 0
.sysctl_vsyscall 4 4 0
.xtime 16 16 0
.jiffies 8 8 0
.vsyscall_1 41 40 -1
.vsyscall_2 8 8 0
.vsyscall_3 8 8 0
.data.init_task 8192 8192 0
.init.text 106076 87536 -18540
.init.data 44016 44016 0
.init.setup 2160 2160 0
.initcall.init 1048 1048 0
.con_initcall.init 8 8 0
.security_initcall.init 0 0 0
.altinstructions 331 307 -24
.altinstr_replacement 46 43 -3
.exit.text 1548 1147 -401
.init.ramfs 134 134 0
.comment 11592 11592 0
.note.GNU-stack 0 0 0
Kurt
--
It is easier to write an incorrect program than understand a correct
one.
prev parent reply other threads:[~2006-01-08 7:14 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-06 10:37 [patch 1/7] Make __always_inline actually force always inlining Arjan van de Ven
2006-01-06 10:38 ` [patch 2/7] enable unit-at-a-time optimisations for gcc4 Arjan van de Ven
2006-01-06 17:18 ` Jeff Garzik
2006-01-06 18:48 ` Sam Ravnborg
2006-01-06 19:00 ` Arjan van de Ven
2006-01-06 19:02 ` Jeff Garzik
2006-01-06 23:56 ` Sam Ravnborg
2006-01-07 0:05 ` Andi Kleen
2006-01-07 0:20 ` Matt Mackall
2006-01-07 1:11 ` Andi Kleen
2006-01-07 8:47 ` Sam Ravnborg
2006-01-07 9:07 ` Andrew Morton
2006-01-07 10:03 ` Sam Ravnborg
2006-01-07 10:13 ` Andrew Morton
2006-01-07 12:00 ` Sam Ravnborg
2006-01-06 10:39 ` [patch 3/7] mark several functions __always_inline Arjan van de Ven
2006-01-06 10:41 ` [patch 4/7] Mark some key VFS functions as __always_inline Arjan van de Ven
2006-01-06 10:50 ` Al Viro
2006-01-06 10:42 ` [patch 5/7] uninline capable() Arjan van de Ven
2006-01-06 11:18 ` Michael Buesch
2006-01-06 11:22 ` Arjan van de Ven
2006-01-06 11:26 ` Michael Buesch
2006-01-08 5:51 ` [PATCH 1/4] move capable() to capability.h Randy.Dunlap
2006-01-08 7:45 ` Valdis.Kletnieks
2006-01-08 13:48 ` Randy.Dunlap
2006-01-08 18:02 ` Tim Schmielau
2006-01-09 1:55 ` Randy.Dunlap
2006-01-08 18:15 ` Tim Schmielau
2006-01-08 19:03 ` Andrew Morton
2006-01-08 17:19 ` [patch 5/7] uninline capable() Tim Schmielau
2006-01-07 0:28 ` Matt Mackall
2006-01-06 10:43 ` [patch 6/7] Unlinline a bunch of other functions Arjan van de Ven
2006-01-06 12:11 ` [PATCH] pktcdvd: Un-inline some functions Peter Osterlund
2006-01-06 17:29 ` [patch 6/7] Unlinline a bunch of other functions Jeff Garzik
2006-01-07 6:28 ` Andrew Morton
2006-01-06 10:45 ` [patch 7/7] Make "inline" no longer mandatory for gcc 4.x Arjan van de Ven
2006-01-06 17:31 ` Jeff Garzik
2006-01-06 19:35 ` Arjan van de Ven
2006-01-07 6:33 ` Andrew Morton
2006-01-07 8:34 ` Arjan van de Ven
2006-01-07 19:05 ` Kurt Wall
2006-01-07 19:10 ` Arjan van de Ven
2006-01-07 19:44 ` Arjan van de Ven
2006-01-07 22:13 ` Kurt Wall
2006-01-08 3:16 ` Kurt Wall
2006-01-08 3:56 ` Mitchell Blank Jr
2006-01-08 7:14 ` Kurt Wall [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060108071416.GD26614@kurtwerks.com \
--to=kwall@kurtwerks.com \
--cc=akpm@osdl.org \
--cc=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mitch@sfgoth.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.