[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <r3584n3-sq21-qo49-9sp5-r3qp6o611s55@syhkavp.arg>
Date: Thu, 25 Feb 2021 12:19:36 -0500 (EST)
From: Nicolas Pitre <nico@...xnic.net>
To: Masahiro Yamada <masahiroy@...nel.org>
cc: linux-kbuild@...r.kernel.org, Christoph Hellwig <hch@....de>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Jessica Yu <jeyu@...nel.org>,
Sami Tolvanen <samitolvanen@...gle.com>,
linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH 0/4] kbuild: build speed improvment of
CONFIG_TRIM_UNUSED_KSYMS
On Fri, 26 Feb 2021, Masahiro Yamada wrote:
>
> Now CONFIG_TRIM_UNUSED_KSYMS is revived, but Linus is still unhappy
> about the build speed.
>
> I re-implemented this feature, and the build time cost is now
> almost unnoticeable level.
>
> I hope this makes Linus happy.
:-)
I'm surprised to see that Linus is using this feature. When disabled
(the default) this should have had no impact on the build time.
This feature provides a nice security advantage by significantly
reducing the kernel input surface. And people are using that also to
better what third party vendor can and cannot do with a distro kernel,
etc. But that's not the reason why I implemented this feature in the
first place.
My primary goal was to efficiently reduce the kernel binary size using
LTO even with kernel modules enabled. Each EXPORT_SYMBOL() created a
symbol dependency that prevented LTO from optimizing out the related
code even though a tiny fraction of those exported symbols were needed.
The idea behind the recursion was to catch those cases where disabling
an exported symbol within a module would optimize out references to more
exported symbols that, in turn, could be disabled and possibly trigger
yet more code elimination. There is no way that can be achieved without
extra compiler passes in a recursive manner.
Nicolas
Powered by blists - more mailing lists