From: Arnd Bergmann <arnd@arndb.de>
To: Nicholas Piggin <npiggin@gmail.com>
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: Wed, 24 Aug 2016 17:01:30 +0200 [thread overview]
Message-ID: <2147968.tzghefjZMo@wuerfel> (raw)
In-Reply-To: <20160824205646.4d6170e1@roar.ozlabs.ibm.com>
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.
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.
Arnd
WARNING: multiple messages have this Message-ID (diff)
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] arm: add an option for erratum 657417
Date: Wed, 24 Aug 2016 17:01:30 +0200 [thread overview]
Message-ID: <2147968.tzghefjZMo@wuerfel> (raw)
In-Reply-To: <20160824205646.4d6170e1@roar.ozlabs.ibm.com>
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.
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.
Arnd
next prev parent reply other threads:[~2016-08-24 15:02 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 [this message]
2016-08-24 15:01 ` Arnd Bergmann
2016-08-26 11:17 ` Nicholas Piggin
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=2147968.tzghefjZMo@wuerfel \
--to=arnd@arndb.de \
--cc=amodra@gmail.com \
--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=npiggin@gmail.com \
--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.