Messages in this thread | | | From | Arnd Bergmann <> | Date | Wed, 24 Feb 2021 17:04:47 +0100 | Subject | Re: [GIT PULL v2] clang-lto for v5.12-rc1 |
| |
On Wed, Feb 24, 2021 at 1:10 AM Alexander Lobakin <alobakin@pm.me> wrote: > From: Linus Torvalds <torvalds@linux-foundation.org> Date: Tue, 23 Feb 2021 12:33:05 -0800 >> > On Tue, Feb 23, 2021 at 9:49 AM Linus Torvalds <torvalds@linux-foundation.org> wrote: > > > On Mon, Feb 22, 2021 at 3:11 PM Kees Cook <keescook@chromium.org> wrote: > > > > > > > > While x86 LTO enablement is done[1], it depends on some objtool > > > > clean-ups[2], though it appears those actually have been in linux-next > > > > (via tip/objtool/core), so it's possible that if that tree lands [..] > > > > > > That tree is actually next on my list of things to merge after this > > > one, so it should be out soonish. > > > > "soonish" turned out to be later than I thought, because my "build > > changes" set of pulls included the module change that I then wasted a > > lot of time on trying to figure out why it slowed down my build so > > much. > > I guess it's about CONFIG_TRIM_UNUSED_KSYMS you disabled in your tree. > Well, it's actually widely used, mostly in the embedded world where > there are often no out-of-tree modules, but a need to save as much > space as possible. > For full-blown systems and distributions it's almost needless, right.
Generally, CONFIG_TRIM_UNUSED_KSYMS helps mostly when combined with either LTO or --gc-sections (CONFIG_HAVE_LD_DEAD_CODE_DATA_ELIMINATION), though the effect seems to be smaller than I expected. For example on m68k:
4005135 1374302 167108 5546545 54a231 vmlinux-normal 3916254 1378078 167108 5461440 5355c0 vmlinux+trim 4012933 1362514 164280 5539727 54878f vmlinux+gcsection 3797884 1334194 164640 5296718 50d24e vmlinux+gcsection+trim
For arm64 defconfig, CONFIG_TRIM_UNUSED_KSYMS saves around 700KB by itself, or when combined with either gc-sections or LTO, but saves a full megabyte when all three are combined:
text data bss dec hex filename 16570322 10998617 506468 28075407 1ac658f defconfig/vmlinux 16318793 10569913 506468 27395174 1a20466 trim_defconfig/vmlinux 16281234 10984848 504291 27770373 1a7be05 gc_defconfig/vmlinux 16029705 10556880 504355 27090940 19d5ffc gc+trim_defconfig/vmlinux 17040142 11102945 504196 28647283 1b51f73 thinlto_defconfig/vmlinux 16788613 10663201 504196 27956010 1aa932a thinlto+trim_defconfig/vmlinux 16347062 11043384 502499 27892945 1a99cd1 gc+thinlto_defconfig/vmlinux 15759453 10532792 502395 26794640 198da90 gc+thinlto+trim_defconfig/vmlinux
However, the combination of thinlto and trim indeed has a steep cost in compile time, taking almost twice as long as a normal defconfig (gc-sections makes it slightly faster).
==== defconfig ==== 332.001786355 seconds time elapsed 8599.464163000 seconds user 676.919635000 seconds sys ==== trim_defconfig ==== 448.378576012 seconds time elapsed 10735.489271000 seconds user 964.006504000 seconds sys ==== gc_defconfig ==== 324.347492236 seconds time elapsed 8465.785800000 seconds user 614.899797000 seconds sys ==== gc+trim_defconfig ==== 429.188875620 seconds time elapsed 10203.759658000 seconds user 871.307973000 seconds sys ==== thinlto_defconfig ==== 389.793540200 seconds time elapsed 9491.665320000 seconds user 664.858109000 seconds sys ==== thinlto+trim_defconfig ==== 580.431820561 seconds time elapsed 11429.515538000 seconds user 1056.985745000 seconds sys ==== gc+thinlto_defconfig ==== 389.484364525 seconds time elapsed 9473.831980000 seconds user 675.057675000 seconds sys ==== gc+thinlto+trim_defconfig ==== 580.824912807 seconds time elapsed 11433.650337000 seconds user 1049.845569000 seconds sys
Arnd
| |