linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andi Kleen <andi@firstfloor.org>
To: viro@zeniv.linux.org.uk
Cc: linux-fsdevel@vger.kernel.org, Andi Kleen <ak@linux.intel.com>
Subject: [PATCH] lto, fs: Avoid static variable in linux/fs.h
Date: Thu, 21 Dec 2017 15:36:16 -0800	[thread overview]
Message-ID: <20171221233616.31820-1-andi@firstfloor.org> (raw)

From: Andi Kleen <ak@linux.intel.com>

linux/fs.h has a initialized static variable kernel_read_file_str. It doesn't
make much sense to have a static variable in a frequently included
header file. With LTO -fno-toplevel-reorder gcc is unable to eliminate
it, which leads to a lot of unnecessary duplicated copies.

Move the static into the scope of the only inline that uses it,
this tells the compiler enough to not duplicate it. Right now
the inline is only called from one place, so that is ok. If it was
called from more places would need to move it somewhere else
to avoid unnecessary copies.

With LTO this avoids ~100k unnecessary data segment for a x86 defconfig
build. Even without LTO it doesn't make any sense.

Cc: viro@zeniv.linux.org.uk
Signed-off-by: Andi Kleen <ak@linux.intel.com>
---
 include/linux/fs.h | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/linux/fs.h b/include/linux/fs.h
index 2995a271ec46..2f02f1c991c9 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -2821,12 +2821,12 @@ enum kernel_read_file_id {
 	__kernel_read_file_id(__fid_enumify)
 };
 
-static const char * const kernel_read_file_str[] = {
-	__kernel_read_file_id(__fid_stringify)
-};
-
 static inline const char *kernel_read_file_id_str(enum kernel_read_file_id id)
 {
+	static const char * const kernel_read_file_str[] = {
+		__kernel_read_file_id(__fid_stringify)
+	};
+
 	if ((unsigned)id >= READING_MAX_ID)
 		return kernel_read_file_str[READING_UNKNOWN];
 
-- 
2.15.0

                 reply	other threads:[~2017-12-21 23:45 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20171221233616.31820-1-andi@firstfloor.org \
    --to=andi@firstfloor.org \
    --cc=ak@linux.intel.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).