All of lore.kernel.org
 help / color / mirror / Atom feed
From: Nicholas Piggin <npiggin@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Nicolas Pitre <nicolas.pitre@linaro.org>,
	linux-arch@vger.kernel.org,
	Segher Boessenkool <segher@kernel.crashing.org>,
	Alan Modra <amodra@gmail.com>,
	linux-kbuild@vger.kernel.org,
	Russell King <linux@armlinux.org.uk>,
	Julian Brown <julian@codesourcery.com>,
	Michal Marek <mmarek@suse.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>,
	Sam Ravnborg <sam@ravnborg.org>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH] arm: add an option for erratum 657417
Date: Fri, 26 Aug 2016 21:17:29 +1000	[thread overview]
Message-ID: <20160826211729.592ff5cd@roar.ozlabs.ibm.com> (raw)
In-Reply-To: <2147968.tzghefjZMo@wuerfel>

On Wed, 24 Aug 2016 17:01:30 +0200
Arnd Bergmann <arnd@arndb.de> wrote:

> On Wednesday, August 24, 2016 8:56:46 PM CEST Nicholas Piggin wrote:
> > On Wed, 24 Aug 2016 19:05:30 +1000
> > Nicholas Piggin <npiggin@gmail.com> wrote:  
> > > Thanks, I'll take a look.  
> > 
> > Okay, I can't reproduce your bad linking times even with gc-sections. It's
> > possible I'm doing something wrong, but with my patches + your patch and
> > standard arm allyesconfig:
> > 
> >   20:33:56  AR      built-in.o
> >   20:33:57  LD      vmlinux.o
> >   MODPOST vmlinux.o
> >   20:34:12  GEN     .version
> >   CHK     include/generated/compile.h
> >   UPD     include/generated/compile.h
> >   CC      init/version.o
> >   AR      init/built-in.o
> >   20:34:24  KSYM    .tmp_kallsyms1.o
> >   20:34:45  KSYM    .tmp_kallsyms2.o
> >   20:34:54  LD      vmlinux
> >   20:35:07  SORTEX  vmlinux
> >   20:35:07  SYSMAP  System.map
> > 
> > I have about 71 seconds for the final link phase.  
> 
> 
> I've tracked down my remaining build time regression to
> a bad binutils snapshot (2.26.51) I had been using, and upgraded
> to the 2.27 release now, which is roughly the same as what
> you have:
> 
> 14:45:41   LINK    vmlinux
> 14:45:41  AR      built-in.o
> 14:45:42  LD      vmlinux.o
> 14:51:49   MODPOST vmlinux.o
> 14:51:51  GEN     .version
> 14:51:51   CHK     include/generated/compile.h
>   UPD     include/generated/compile.h
> 14:51:51   CC      init/version.o
> 14:51:52   AR      init/built-in.o
> 14:52:04  KSYM    .tmp_kallsyms1.o
> 14:52:31  KSYM    .tmp_kallsyms2.o
> 14:52:43  LD      vmlinux
> 14:52:55  SORTEX  vmlinux
> 14:52:55  SYSMAP  System.map
> 14:52:56   OBJCOPY arch/arm/boot/Image
> 
> The long minutes that were spent in "arm-linux-gnueabi-ld 
> -r -o vmlinux.o --whole-archive built-in.o" are all gone now.

Thanks for tracking it down, that's good to hear.


> I still see a problem with big-endian builds failing with
> thinarc/gc-sections, I'll investigate that some other day,
> or you could have a look at that if you want to make sure
> it's an ARM specific problem, not something with your
> patches in general.
> 
> The patch that I sent for enabling the two on ARM blocks
> out CONFIG_CPU_BIG_ENDIAN, so just revert that hunk to see
> the problem. It's possible that it only breaks when doing
> a big-endian build after a little-endian build without
> a "make clean" inbetween.

I'm able to build big endian ARM allyesconfig with thin
archives and gc-sections, worked fine.

There have been a few bugs in powerpc when failing to notice
the change when endian of builds was swapped, so maybe you
got bitten by something similar.

Thanks,
Nick

WARNING: multiple messages have this Message-ID (diff)
From: Nicholas Piggin <npiggin@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-arm-kernel@lists.infradead.org,
	Russell King <linux@armlinux.org.uk>,
	linux-kbuild@vger.kernel.org,
	Nicolas Pitre <nicolas.pitre@linaro.org>,
	Julian Brown <julian@codesourcery.com>,
	Alan Modra <amodra@gmail.com>,
	Segher Boessenkool <segher@kernel.crashing.org>,
	linux-arch@vger.kernel.org, Michal Marek <mmarek@suse.com>,
	Sam Ravnborg <sam@ravnborg.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>
Subject: Re: [PATCH] arm: add an option for erratum 657417
Date: Fri, 26 Aug 2016 21:17:29 +1000	[thread overview]
Message-ID: <20160826211729.592ff5cd@roar.ozlabs.ibm.com> (raw)
Message-ID: <20160826111729.Al-48h-2-unXRqpTgIxkrtYaPtThzivBkWC8kzocleA@z> (raw)
In-Reply-To: <2147968.tzghefjZMo@wuerfel>

On Wed, 24 Aug 2016 17:01:30 +0200
Arnd Bergmann <arnd@arndb.de> wrote:

> On Wednesday, August 24, 2016 8:56:46 PM CEST Nicholas Piggin wrote:
> > On Wed, 24 Aug 2016 19:05:30 +1000
> > Nicholas Piggin <npiggin@gmail.com> wrote:  
> > > Thanks, I'll take a look.  
> > 
> > Okay, I can't reproduce your bad linking times even with gc-sections. It's
> > possible I'm doing something wrong, but with my patches + your patch and
> > standard arm allyesconfig:
> > 
> >   20:33:56  AR      built-in.o
> >   20:33:57  LD      vmlinux.o
> >   MODPOST vmlinux.o
> >   20:34:12  GEN     .version
> >   CHK     include/generated/compile.h
> >   UPD     include/generated/compile.h
> >   CC      init/version.o
> >   AR      init/built-in.o
> >   20:34:24  KSYM    .tmp_kallsyms1.o
> >   20:34:45  KSYM    .tmp_kallsyms2.o
> >   20:34:54  LD      vmlinux
> >   20:35:07  SORTEX  vmlinux
> >   20:35:07  SYSMAP  System.map
> > 
> > I have about 71 seconds for the final link phase.  
> 
> 
> I've tracked down my remaining build time regression to
> a bad binutils snapshot (2.26.51) I had been using, and upgraded
> to the 2.27 release now, which is roughly the same as what
> you have:
> 
> 14:45:41   LINK    vmlinux
> 14:45:41  AR      built-in.o
> 14:45:42  LD      vmlinux.o
> 14:51:49   MODPOST vmlinux.o
> 14:51:51  GEN     .version
> 14:51:51   CHK     include/generated/compile.h
>   UPD     include/generated/compile.h
> 14:51:51   CC      init/version.o
> 14:51:52   AR      init/built-in.o
> 14:52:04  KSYM    .tmp_kallsyms1.o
> 14:52:31  KSYM    .tmp_kallsyms2.o
> 14:52:43  LD      vmlinux
> 14:52:55  SORTEX  vmlinux
> 14:52:55  SYSMAP  System.map
> 14:52:56   OBJCOPY arch/arm/boot/Image
> 
> The long minutes that were spent in "arm-linux-gnueabi-ld 
> -r -o vmlinux.o --whole-archive built-in.o" are all gone now.

Thanks for tracking it down, that's good to hear.


> I still see a problem with big-endian builds failing with
> thinarc/gc-sections, I'll investigate that some other day,
> or you could have a look at that if you want to make sure
> it's an ARM specific problem, not something with your
> patches in general.
> 
> The patch that I sent for enabling the two on ARM blocks
> out CONFIG_CPU_BIG_ENDIAN, so just revert that hunk to see
> the problem. It's possible that it only breaks when doing
> a big-endian build after a little-endian build without
> a "make clean" inbetween.

I'm able to build big endian ARM allyesconfig with thin
archives and gc-sections, worked fine.

There have been a few bugs in powerpc when failing to notice
the change when endian of builds was swapped, so maybe you
got bitten by something similar.

Thanks,
Nick

WARNING: multiple messages have this Message-ID (diff)
From: npiggin@gmail.com (Nicholas Piggin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: add an option for erratum 657417
Date: Fri, 26 Aug 2016 21:17:29 +1000	[thread overview]
Message-ID: <20160826211729.592ff5cd@roar.ozlabs.ibm.com> (raw)
In-Reply-To: <2147968.tzghefjZMo@wuerfel>

On Wed, 24 Aug 2016 17:01:30 +0200
Arnd Bergmann <arnd@arndb.de> wrote:

> On Wednesday, August 24, 2016 8:56:46 PM CEST Nicholas Piggin wrote:
> > On Wed, 24 Aug 2016 19:05:30 +1000
> > Nicholas Piggin <npiggin@gmail.com> wrote:  
> > > Thanks, I'll take a look.  
> > 
> > Okay, I can't reproduce your bad linking times even with gc-sections. It's
> > possible I'm doing something wrong, but with my patches + your patch and
> > standard arm allyesconfig:
> > 
> >   20:33:56  AR      built-in.o
> >   20:33:57  LD      vmlinux.o
> >   MODPOST vmlinux.o
> >   20:34:12  GEN     .version
> >   CHK     include/generated/compile.h
> >   UPD     include/generated/compile.h
> >   CC      init/version.o
> >   AR      init/built-in.o
> >   20:34:24  KSYM    .tmp_kallsyms1.o
> >   20:34:45  KSYM    .tmp_kallsyms2.o
> >   20:34:54  LD      vmlinux
> >   20:35:07  SORTEX  vmlinux
> >   20:35:07  SYSMAP  System.map
> > 
> > I have about 71 seconds for the final link phase.  
> 
> 
> I've tracked down my remaining build time regression to
> a bad binutils snapshot (2.26.51) I had been using, and upgraded
> to the 2.27 release now, which is roughly the same as what
> you have:
> 
> 14:45:41   LINK    vmlinux
> 14:45:41  AR      built-in.o
> 14:45:42  LD      vmlinux.o
> 14:51:49   MODPOST vmlinux.o
> 14:51:51  GEN     .version
> 14:51:51   CHK     include/generated/compile.h
>   UPD     include/generated/compile.h
> 14:51:51   CC      init/version.o
> 14:51:52   AR      init/built-in.o
> 14:52:04  KSYM    .tmp_kallsyms1.o
> 14:52:31  KSYM    .tmp_kallsyms2.o
> 14:52:43  LD      vmlinux
> 14:52:55  SORTEX  vmlinux
> 14:52:55  SYSMAP  System.map
> 14:52:56   OBJCOPY arch/arm/boot/Image
> 
> The long minutes that were spent in "arm-linux-gnueabi-ld 
> -r -o vmlinux.o --whole-archive built-in.o" are all gone now.

Thanks for tracking it down, that's good to hear.


> I still see a problem with big-endian builds failing with
> thinarc/gc-sections, I'll investigate that some other day,
> or you could have a look at that if you want to make sure
> it's an ARM specific problem, not something with your
> patches in general.
> 
> The patch that I sent for enabling the two on ARM blocks
> out CONFIG_CPU_BIG_ENDIAN, so just revert that hunk to see
> the problem. It's possible that it only breaks when doing
> a big-endian build after a little-endian build without
> a "make clean" inbetween.

I'm able to build big endian ARM allyesconfig with thin
archives and gc-sections, worked fine.

There have been a few bugs in powerpc when failing to notice
the change when endian of builds was swapped, so maybe you
got bitten by something similar.

Thanks,
Nick

  reply	other threads:[~2016-08-26 11:17 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-12  8:19 [PATCH] arm: add an option for erratum 657417 Nicholas Piggin
2016-08-12  8:19 ` Nicholas Piggin
2016-08-12 12:33 ` Russell King - ARM Linux
2016-08-12 12:33   ` Russell King - ARM Linux
2016-08-12 13:15   ` Nicholas Piggin
2016-08-12 13:15     ` Nicholas Piggin
2016-08-12 13:49     ` Ard Biesheuvel
2016-08-12 13:49       ` Ard Biesheuvel
2016-08-12 13:50       ` Ard Biesheuvel
2016-08-12 13:50         ` Ard Biesheuvel
2016-08-12 13:50         ` Ard Biesheuvel
2016-08-12 13:52         ` Russell King - ARM Linux
2016-08-12 13:52           ` Russell King - ARM Linux
2016-08-12 13:54           ` Ard Biesheuvel
2016-08-12 13:54             ` Ard Biesheuvel
2016-08-12 13:51       ` Russell King - ARM Linux
2016-08-12 13:51         ` Russell King - ARM Linux
2016-08-12 14:17   ` Robin Murphy
2016-08-12 14:17     ` Robin Murphy
2016-08-12 14:23     ` Russell King - ARM Linux
2016-08-12 14:23       ` Russell King - ARM Linux
2016-08-12 14:32       ` Russell King - ARM Linux
2016-08-12 14:32         ` Russell King - ARM Linux
2016-08-12 14:32         ` Russell King - ARM Linux
2016-08-23 12:01 ` Arnd Bergmann
2016-08-23 12:01   ` Arnd Bergmann
2016-08-24  4:00   ` Nicholas Piggin
2016-08-24  4:00     ` Nicholas Piggin
2016-08-24  7:41     ` Arnd Bergmann
2016-08-24  7:41       ` Arnd Bergmann
2016-08-24  7:41       ` Arnd Bergmann
2016-08-24  9:05       ` Nicholas Piggin
2016-08-24  9:05         ` Nicholas Piggin
2016-08-24 10:56         ` Nicholas Piggin
2016-08-24 10:56           ` Nicholas Piggin
2016-08-24 10:56           ` Nicholas Piggin
2016-08-24 12:06           ` Nicholas Piggin
2016-08-24 12:06             ` Nicholas Piggin
2016-08-24 15:01           ` Arnd Bergmann
2016-08-24 15:01             ` Arnd Bergmann
2016-08-26 11:17             ` Nicholas Piggin [this message]
2016-08-26 11:17               ` Nicholas Piggin
2016-08-26 11:17               ` Nicholas Piggin
2016-08-26 14:07               ` Arnd Bergmann
2016-08-26 14:07                 ` Arnd Bergmann
2016-08-26 14:07                 ` Arnd Bergmann

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=20160826211729.592ff5cd@roar.ozlabs.ibm.com \
    --to=npiggin@gmail.com \
    --cc=amodra@gmail.com \
    --cc=arnd@arndb.de \
    --cc=julian@codesourcery.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kbuild@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=mmarek@suse.com \
    --cc=nicolas.pitre@linaro.org \
    --cc=sam@ravnborg.org \
    --cc=segher@kernel.crashing.org \
    --cc=sfr@canb.auug.org.au \
    /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.