All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
To: Sam Ravnborg <sam@ravnborg.org>
Cc: Alan Modra <amodra@gmail.com>,
	linux-arch@vger.kernel.org, linux-kbuild@vger.kernel.org,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>
Subject: Re: [PATCH] kbuild: provide THIN_ARCHIVES option for all architectures
Date: Tue, 30 May 2017 09:49:05 +1000	[thread overview]
Message-ID: <20170530094905.03ecc254@roar.ozlabs.ibm.com> (raw)
In-Reply-To: <20170529185251.GA3359@ravnborg.org>

On Mon, 29 May 2017 20:52:51 +0200
Sam Ravnborg <sam@ravnborg.org> wrote:

> Hi Nicholas.
> 
> > Supporting two different intermediate-artifact packaging schemes
> > was only ever intended as a temporary transition.
> > 
> > This has so far caused no problems for powerpc, after a small fix
> > for how the arch invoked ar. So now allow any arch to select the
> > option, continue defaulting to N.  
> 
> Alan Modra recommended this approach several years ago, and I think
> Stephen was the first to implement this for the kernel.
> It would be good to have the rational whay ar is better than ld -r
> included in the commit message for later reference.

We *are* using Stephen's thin archives build infrastructure in the
kernel already. Only powerpc is using it so far: a5967db9af

The big one for powerpc build is that  the linker keeps relative
location of input sections the same, so as you link into larger
built-in.o files, there is less opportunity to place code optimally.
x86 may not care so much, but some other archs will.

The build output size improvement is nice for everyone though.

> I also recall that using ar gave some small kernel size reductions
> from last time we played with this.
> This info could also be nice to give a rough idea of the impact.

There is some explanation in sfr's patch. It's not thin archives
as such, but rather we have to link with --whole-archive, but it
was a very small impact.

IIRC today's final link is technically buggy without that option,
it's just that in practice the top-level built-in.o files pull in
so much that the linker will never discard one.

Thanks,
Nick

  reply	other threads:[~2017-05-29 23:49 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-29  8:11 [PATCH] kbuild: provide THIN_ARCHIVES option for all architectures Nicholas Piggin
2017-05-29 10:33 ` Stephen Rothwell
2017-05-29 14:34   ` Nicholas Piggin
2017-05-29 17:03 ` Linus Torvalds
2017-05-29 17:14   ` Linus Torvalds
2017-05-29 23:13     ` Nicholas Piggin
2017-05-30  3:22       ` Linus Torvalds
2017-05-30  3:55         ` Nicholas Piggin
2017-05-30  3:54       ` Linus Torvalds
2017-05-29 18:52 ` Sam Ravnborg
2017-05-29 23:49   ` Nicholas Piggin [this message]
2017-05-31 21:13 ` Arnd Bergmann
2017-06-04 23:17   ` Masahiro Yamada
2017-06-05  7:00     ` Nicholas Piggin

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=20170530094905.03ecc254@roar.ozlabs.ibm.com \
    --to=npiggin@gmail.com \
    --cc=amodra@gmail.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=sam@ravnborg.org \
    --cc=sfr@canb.auug.org.au \
    --cc=torvalds@linux-foundation.org \
    /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.