All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Burton <paul.burton@imgtec.com>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: <linux-mips@linux-mips.org>, Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH 0/6] MIPS: Use thin archives & dead code elimination
Date: Fri, 21 Oct 2016 08:45:47 +0100	[thread overview]
Message-ID: <1724594.nvOo2qz5cT@np-p-burton> (raw)
In-Reply-To: <20161021115147.0f6eea51@roar.ozlabs.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 1625 bytes --]

Hi Nick,

On Friday, 21 October 2016 11:51:47 BST Nicholas Piggin wrote:
> Paul Burton <paul.burton@imgtec.com> wrote:
> > This series fixes a few issues with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
> > and then enables it, along with CONFIG_THIN_ARCHIVES, for MIPS. This
> > 
> > leads to a typical generic kernel build becoming ~5% smaller:
> >   add/remove: 0/3028 grow/shrink: 1/14 up/down: 18/-457362 (-457344)
> >   ...
> >   Total: Before=9001030, After=8543686, chg -5.08%
> > 
> > Applies atop v4.9-rc1.
> 
> Very nice, and thanks for the kbuild fixes, I think they all look sane.
> 
> Let's try to get those kbuild fixes in through the kbuild tree first
> (which has some other fixes required for 4.9). I can take them and send
> them to kbuild maintainer if you like.

That sounds great :)

> On powerpc we'll likely provide an option to select these manually for
> 4.9 because there has been the odd toolchain issue come up, so that's
> something to consider.

I imagine the MIPS bits will probably be v4.10 material, but hopefully Ralf 
can get them into -next as soon as possible after the kbuild bits are in, 
which should give us some time to discover any toolchain issues.

> For your linker script, you may consider putting the function sections
> into the same input as other text. TEXT_TEXT does not include .text.*,
> so mips's .text.* below it will catch those.
> 
> You may just open-code your TEXT_TEXT, and have:
> 
> *(.text.hot .text .text.fixup .text.unlikely .text.[0-9a-zA-Z_]*)
> 
> or similar.

Ah, so are you saying that would give the linker more scope for discarding 
things?

Thanks,
    Paul

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

WARNING: multiple messages have this Message-ID (diff)
From: Paul Burton <paul.burton@imgtec.com>
To: Nicholas Piggin <npiggin@gmail.com>
Cc: linux-mips@linux-mips.org, Ralf Baechle <ralf@linux-mips.org>
Subject: Re: [PATCH 0/6] MIPS: Use thin archives & dead code elimination
Date: Fri, 21 Oct 2016 08:45:47 +0100	[thread overview]
Message-ID: <1724594.nvOo2qz5cT@np-p-burton> (raw)
Message-ID: <20161021074547.058hhoItN7rJQVtuvUxq4NHB9yIoWYE6SUMG14Cdhao@z> (raw)
In-Reply-To: <20161021115147.0f6eea51@roar.ozlabs.ibm.com>

[-- Attachment #1: Type: text/plain, Size: 1625 bytes --]

Hi Nick,

On Friday, 21 October 2016 11:51:47 BST Nicholas Piggin wrote:
> Paul Burton <paul.burton@imgtec.com> wrote:
> > This series fixes a few issues with CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
> > and then enables it, along with CONFIG_THIN_ARCHIVES, for MIPS. This
> > 
> > leads to a typical generic kernel build becoming ~5% smaller:
> >   add/remove: 0/3028 grow/shrink: 1/14 up/down: 18/-457362 (-457344)
> >   ...
> >   Total: Before=9001030, After=8543686, chg -5.08%
> > 
> > Applies atop v4.9-rc1.
> 
> Very nice, and thanks for the kbuild fixes, I think they all look sane.
> 
> Let's try to get those kbuild fixes in through the kbuild tree first
> (which has some other fixes required for 4.9). I can take them and send
> them to kbuild maintainer if you like.

That sounds great :)

> On powerpc we'll likely provide an option to select these manually for
> 4.9 because there has been the odd toolchain issue come up, so that's
> something to consider.

I imagine the MIPS bits will probably be v4.10 material, but hopefully Ralf 
can get them into -next as soon as possible after the kbuild bits are in, 
which should give us some time to discover any toolchain issues.

> For your linker script, you may consider putting the function sections
> into the same input as other text. TEXT_TEXT does not include .text.*,
> so mips's .text.* below it will catch those.
> 
> You may just open-code your TEXT_TEXT, and have:
> 
> *(.text.hot .text .text.fixup .text.unlikely .text.[0-9a-zA-Z_]*)
> 
> or similar.

Ah, so are you saying that would give the linker more scope for discarding 
things?

Thanks,
    Paul

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

  reply	other threads:[~2016-10-21  7:46 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-20 20:26 [PATCH 0/6] MIPS: Use thin archives & dead code elimination Paul Burton
2016-10-20 20:26 ` Paul Burton
2016-10-20 20:27 ` [PATCH 1/6] kbuild: Keep device tree tables though " Paul Burton
2016-10-20 20:27   ` Paul Burton
2016-10-21  9:33   ` Sergei Shtylyov
2016-10-20 20:27 ` [PATCH 2/6] kbuild: Keep .init.setup section through " Paul Burton
2016-10-20 20:27   ` Paul Burton
2016-10-20 20:27 ` [PATCH 3/6] kbuild: Keep PCI fixups " Paul Burton
2016-10-20 20:27   ` Paul Burton
2016-10-20 20:27 ` [PATCH 4/6] kbuild: Keep earlycon table " Paul Burton
2016-10-20 20:27   ` Paul Burton
2016-10-20 20:27 ` [PATCH 5/6] MIPS: Ensure bss section ends on a long-aligned address Paul Burton
2016-10-20 20:27   ` Paul Burton
2016-11-04  8:46   ` Marcin Nowakowski
2016-11-04  8:46     ` Marcin Nowakowski
2016-10-20 20:27 ` [PATCH 6/6] MIPS: Use thin archives & dead code elimination Paul Burton
2016-10-20 20:27   ` Paul Burton
2016-10-21  0:51 ` [PATCH 0/6] " Nicholas Piggin
2016-10-21  0:51   ` Nicholas Piggin
2016-10-21  7:45   ` Paul Burton [this message]
2016-10-21  7:45     ` Paul Burton
2016-10-21  8:47     ` Nicholas Piggin
2016-10-21  8:47       ` 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=1724594.nvOo2qz5cT@np-p-burton \
    --to=paul.burton@imgtec.com \
    --cc=linux-mips@linux-mips.org \
    --cc=npiggin@gmail.com \
    --cc=ralf@linux-mips.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.