From: Feng Tang <feng.tang@intel.com>
To: Masahiro Yamada <masahiroy@kernel.org>,
Michal Marek <michal.lkml@markovi.net>,
Andrew Morton <akpm@linux-foundation.org>,
linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
andi.kleen@intel.com, ying.huang@intel.com,
andriy.shevchenko@intel.com, Feng Tang <feng.tang@intel.com>
Subject: [RFC PATCH] makefile: add debug option to enable function aligned on 32 bytes
Date: Thu, 23 Jul 2020 11:30:01 +0800 [thread overview]
Message-ID: <1595475001-90945-1-git-send-email-feng.tang@intel.com> (raw)
Recently 0day reported many strange performance changes (regression
or improvement), in which there was no obvious relation between
the culprit commit and the benchmark at the first look, and it causes
people to doubt the test itself is wrong.
Upon further check, many of these cases are caused by the change
to the alignment of kernel text or data, as whole text/data of kernel
are linked together, change in one domain may affect alignments of
other domains.
gcc has an option '-falign-functions=n' to force text aligned, and with
that option enabled, some of those performance changes will be gone,
like [1][2][3].
Add this option so that developers and 0day can easily find performance
bump caused by text alignment change, as tracking these strange bump
is quite time consuming. Though it can't help in other cases like data
alignment changes like [4].
Following is some size data for v5.7 kernel built with a RHEL config
used in 0day:
text data bss dec filename
19738771 13292906 5554236 38585913 vmlinux.noalign
19758591 13297002 5529660 38585253 vmlinux.align32
Raw vmlinux size in bytes:
v5.7 v5.7+align32
253950832 254018000 +0.02%
Some benchmark data, most of them have no big change:
* hackbench: [ -1.8%, +0.5%]
* fsmark: [ -3.2%, +3.4%] # ext4/xfs/btrfs
* kbuild: [ -2.0%, +0.9%]
* will-it-scale: [ -0.5%, +1.8%] # mmap1/pagefault3
* netperf:
- TCP_CRR [+16.6%, +97.4%]
- TCP_RR [-18.5%, -1.8%]
- TCP_STREAM [ -1.1%, +1.9%]
[1] https://lore.kernel.org/lkml/20200114085637.GA29297@shao2-debian/
[2] https://lore.kernel.org/lkml/20200330011254.GA14393@feng-iot/
[3] https://lore.kernel.org/lkml/1d98d1f0-fe84-6df7-f5bd-f4cb2cdb7f45@intel.com/
[4] https://lore.kernel.org/lkml/20200205123216.GO12867@shao2-debian/
Signed-off-by: Feng Tang <feng.tang@intel.com>
---
Makefile | 4 ++++
lib/Kconfig.debug | 11 +++++++++++
2 files changed, 15 insertions(+)
diff --git a/Makefile b/Makefile
index 249a51d25c63..a59105e6f573 100644
--- a/Makefile
+++ b/Makefile
@@ -886,6 +886,10 @@ KBUILD_CFLAGS += $(CC_FLAGS_SCS)
export CC_FLAGS_SCS
endif
+ifdef CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_32B
+KBUILD_CFLAGS += -falign-functions=32
+endif
+
# arch Makefile may override CC so keep this after arch Makefile is included
NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 9ad9210d70a1..c1d52c4f120f 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -365,6 +365,17 @@ config SECTION_MISMATCH_WARN_ONLY
If unsure, say Y.
+config DEBUG_FORCE_FUNCTION_ALIGN_32B
+ bool "Force all function address 32B aligned" if EXPERT
+ help
+ There are cases that a commit from one domain changes the function
+ address alignment of other domains, and cause magic performance
+ bump (regression or improvement). Enable this option will help to
+ verify if the bump is caused by function alignment changes, while
+ it will slightly increase the kernel size and affect icache usage.
+
+ It is mainly for debug and performance tuning use.
+
#
# Select this config option from the architecture Kconfig, if it
# is preferred to always offer frame pointers as a config
--
2.14.1
next reply other threads:[~2020-07-23 3:30 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-23 3:30 Feng Tang [this message]
2020-07-23 3:39 ` [RFC PATCH] makefile: add debug option to enable function aligned on 32 bytes Andrew Morton
2020-07-23 5:13 ` Feng Tang
2020-07-23 6:29 ` Feng Tang
2020-07-24 0:57 ` Andrew Morton
2020-07-24 1:06 ` Feng Tang
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=1595475001-90945-1-git-send-email-feng.tang@intel.com \
--to=feng.tang@intel.com \
--cc=akpm@linux-foundation.org \
--cc=andi.kleen@intel.com \
--cc=andriy.shevchenko@intel.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=michal.lkml@markovi.net \
--cc=torvalds@linux-foundation.org \
--cc=ying.huang@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.