From: Joe Perches <joe@perches.com>
To: "Luck, Tony" <tony.luck@intel.com>
Cc: Doug Thompson <dougthompson@xmission.com>,
Borislav Petkov <bp@alien8.de>,
Mauro Carvalho Chehab <mchehab@kernel.org>,
linux-edac@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] skx_edac: Move a few hundred bytes to text from data using const
Date: Mon, 22 Aug 2016 09:57:23 -0700 [thread overview]
Message-ID: <1471885043.3746.60.camel@perches.com> (raw)
In-Reply-To: <20160822164603.GA24307@intel.com>
On Mon, 2016-08-22 at 09:46 -0700, Luck, Tony wrote:
> On Sun, Aug 21, 2016 at 05:02:41PM -0700, Joe Perches wrote:
> > Marking arrays as const makes for smaller data.
> Joe,
Hi Tony
> "a few hundred" seems to be exaggeration.
>
> Before:
> $ size drivers/edac/skx_edac.ko
> text data bss dec hex filename
> 8435 1024 24 9483 250b drivers/edac/skx_edac.ko
>
> After:
> $ size drivers/edac/skx_edac.ko
> text data bss dec hex filename
> 8531 944 24 9499 251b drivers/edac/skx_edac.ko
>
> so "data" was reduced by 80 bytes, but "text" went up by 96.
Yeah, it was a few hundred in an allyesconfig
and I neglected to test the defconfig.
$ size drivers/edac/skx_edac.o* (x86-64)
text data bss dec hex filename
6677 64 24 6765 1a6d drivers/edac/skx_edac.o.defconfig.new
6546 176 24 6746 1a5a drivers/edac/skx_edac.o.defconfig.old
20609 5744 320 26673 6831 drivers/edac/skx_edac.o.new
20273 6064 320 26657 6821 drivers/edac/skx_edac.o.old
> Net increase of 16 (perhaps because some padding for alignment???)
>
> Making read-only data const is a good idea in general, but
> do we want to do it if it *increases* kernel footprint?
Marking all data const that can be const is a good thing.
It reduces exposure and eliminates unintentional overwriting.
prev parent reply other threads:[~2016-08-22 16:57 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-22 0:02 [PATCH] skx_edac: Move a few hundred bytes to text from data using const Joe Perches
2016-08-22 16:46 ` Luck, Tony
2016-08-22 16:57 ` Joe Perches [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=1471885043.3746.60.camel@perches.com \
--to=joe@perches.com \
--cc=bp@alien8.de \
--cc=dougthompson@xmission.com \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mchehab@kernel.org \
--cc=tony.luck@intel.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.