On 06/21, Arnd Bergmann wrote: > On Wed, Jun 21, 2017 at 2:02 PM, Nicholas Piggin <npiggin@xxxxxxxxx> wrote: > > On Wed, 21 Jun 2017 13:32:17 +0200 > > Arnd Bergmann <arnd@xxxxxxxx> wrote: > > > >> On Wed, Jun 21, 2017 at 1:10 PM, Nicholas Piggin <npiggin@xxxxxxxxx> wrote: > >> > On Wed, 21 Jun 2017 12:49:10 +0200 > >> > Arnd Bergmann <arnd@xxxxxxxx> wrote: > >> > > >> >> On Wed, Jun 21, 2017 at 12:38 PM, Nicholas Piggin <npiggin@xxxxxxxxx> wrote: > >> >> > On Wed, 21 Jun 2017 12:21:16 +0200 > >> >> > Arnd Bergmann <arnd@xxxxxxxx> wrote: > >> >> > > >> >> > >> >> I'm building on top of yesterday's linux-next at the moment, > >> >> with a number of my own patches applied > >> >> > >> >> > I can take a look at ARM and try to get it at least to parity with > >> >> > incremental link. Any particular config options required? > >> >> > >> >> This is the patch I am testing with: > >> >> > >> >> https://pastebin.com/HQuhCEmK > >> >> I have not looked at that in a while, no idea if it works, or > >> >> if it has known problems. > >> >> > >> >> I last posted the patch in March for discussion: > >> >> > >> >> https://patchwork.kernel.org/patch/9626207/ > >> > > >> > Well I just mean the stuff now in kbuild/thin-ac, not the LD_DCDE. > >> > Just want to try getting thin archives up to a point where there are > >> > no serious regressions first. > >> > >> For my build testing, I have now reverted most of my patch and only > >> left the 'select THIN_ARCHIVES'. I'll let you know if I run into problems. > > > > Okay. Currently with the patches in the kbuild tree, thin archives > > actually does better than incremental linking for ARM (defconfig). > > > > 11651574 6090952 418616 18161142 1151df6 vmlinux.thinarc > > 11656118 6095208 418952 18170278 11541a6 vmlinux.inc > > > > In mainline, thin archives is sub-optimal for lib-y libraries (just > > pulls them all in). But now that I test it, even that is better than > > incremental linking for ARM: > > > > 11653926 6090888 418620 18163434 11526ea vmlinux.thinarc > > > > I haven't grabbed that "clk: sunxi-ng: Move all clock types to a library" > > patch yet to check. What tree is it in? I wonder if I could convince you > > to drop that for now and bring it up on linux-kernel/linux-kbuild? I > > think it's quite reasonable to reduce Kconfig hell of very fine grained > > conditional compilation/linking if we can make the toolchain do it for > > us. So we should consider how to support it nicely rather than having > > such hacks IMO. > > [adding Maxime and Stephen to cc] > > Stephen, > > The hack has come to bite us after all, with Nick's proposed change to > CONFIG_THIN_ARCHIVES for all architectures, the entire lib.a file will > end up being linked into each kernel that enables the directory. > > I'm out of other ideas for fixing it, so it seems better to revert back to > individual Kconfig options. Once we enable > CONFIG_LD_DEAD_CODE_DATA_ELIMINATION (which is the > next step after CONFIG_THIN_ARCHIVES), we can simply list > all files, and the linker will drop all unused functions by itself. > Ok. Can you send a revert patch to the list with some information on why we can't do the hack anymore and also Cc lkml/kbuild lists? The commit is in linux-next now as commit 06e226c7fb23 (clk: sunxi-ng: Move all clock types to a library, 2017-06-02). -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project
