From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1948629AbcHETRN (ORCPT ); Fri, 5 Aug 2016 15:17:13 -0400 Received: from mout.kundenserver.de ([217.72.192.73]:60772 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1424626AbcHETRC (ORCPT ); Fri, 5 Aug 2016 15:17:02 -0400 From: Arnd Bergmann To: Nicholas Piggin Cc: linuxppc-dev@lists.ozlabs.org, Stephen Rothwell , "linux-kernel@vger.kernel.org" , "Luis R. Rodriguez" , linux-next@vger.kernel.org, Paul Mackerras , Fengguang Wu , Guenter Roeck Subject: Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Date: Fri, 05 Aug 2016 21:16:00 +0200 Message-ID: <29606723.2uK9PgjbC3@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-31-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20160806021642.5b53b4bf@roar.ozlabs.ibm.com> References: <2852406.SOgyPXcJfO@wuerfel> <20160806021642.5b53b4bf@roar.ozlabs.ibm.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:GLdQSUW5OJceJF8ZcNtGGQ3k3xRQnGCP2t5WZdilj1DuXDj6vq0 LdhD7fkgZnZUO4spJ8n3QO1nfva9u4omLfUIqYewPq4SMr5hAfZF7VijtUQLVu38ZB1zoN7 QguKSgfTtbMJ226j/kWhwcAcpKh9tHoC5aqHCdHSI8ZP67Cf5/f0kKz/124ADjtxmDhGSRb S9U78whmG2b3uHs4jhUlw== X-UI-Out-Filterresults: notjunk:1;V01:K0:opBh0MiDchc=:kvYBVo1pVvnU4fl/yhOvUZ +4kNf1Y7qyss/4hhrjyPaMB+s6IEtgO0B2LUs53LfUKXMZKgyk3tvv7pcZvwZIJ3iNDZ6WFxN dOHirAvSz5DS3AJFpSjXIIWNdYAyxdrOj6d+1INTRNBigVcAi4q2xcoLmsUio+scEaKb+en0l etnh0gKPmAH7c8QAmvDWaoGMLXToCdRoMeDfCGXOEeOHaRGqOy5Dt5xKYZeD5A/qcK9PzDeOT Zrbx+kme7qVWRt/GLLHZxC/qcQHkGePfAyjN63GCbVNBiIahsGdCtyOO8V3zT612dZGx5xWt9 RMKSEU5v54jJbWM6ZwE0OiXvbIi8h6de2balwy02qpQmX44KL1/8QjEDDAh7fZ6q+qrWAMQOj aKUQa000kozZiFVoD7MoMFuYcsMkDsHbNLgpH7SeYKgylkft0VF4zd+T1smKWIwVckjxOS4j9 tM7VmcGeCTNzID547T8gxrFUYQ4sBS06a3w8FQzrixZIHoQ4Z0CUzILD96PekgRJV7XiT5DeT CLRULwrXnGTJq4RimTedHDAiYQzq0KrukwLwn3gpitnnpYtjtxTwYyhIn4tbX3q1HVc40aaRF 9vudu87/V3aU70P0E31M9Qw/6H+7eQNCI2Wado+s2SmbuuX2qvzJK8fMyhE++7W3Yd2U6dVQo EB2n3oJTza/zi0U3ds0LT/BdofQ9m42JVu1ki8dACwLBQWj5vo8sth+9UwbNw3sDsqt1JaCGi 80FMWW1W+4PmoOhE Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Saturday, August 6, 2016 2:16:42 AM CEST Nicholas Piggin wrote: > > > > diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h > > index 0ec807d69f18..7a3ad269fa23 100644 > > --- a/include/asm-generic/vmlinux.lds.h > > +++ b/include/asm-generic/vmlinux.lds.h > > @@ -433,7 +433,7 @@ > > * during second ld run in second ld pass when generating System.map */ > > #define TEXT_TEXT \ > > ALIGN_FUNCTION(); \ > > - *(.text.hot .text .text.fixup .text.unlikely) \ > > + *(.text.hot .text .text.* .text.fixup .text.unlikely) \ > > *(.ref.text) \ > > MEM_KEEP(init.text) \ > > MEM_KEEP(exit.text) \ > > > > > > It also got much faster again, the link time for an allyesconfig > > kernel is now 18 minutes instead of 10 hours, but it's still > > much worse than the 2 minutes I had earlier or the four minutes > > with the previous patch. > > Are you using the patches I just sent? Not yet, I was still busy with the older version, and trying to figure out exactly what went wrong in ld.bfd. FWIW, I first tried to see if the hash tables were just too small, but as it turned out that was not the problem. When I tried to change the default hash table sizes, making them bigger only made things slower. I also found the --hash-size=xxx option, which has a significant impact on runtime speed. Interestingly again, using sizes less than the default made things faster in practice. If we can work out the optimum size for the kernel build, that might shave a few minutes off the total build time. > Either way, you also need > to do the same for data and bss sections as you are using > -fdata-sections too. Right. > I've found virtually no build time regression on powerpc or x86 > when those are taken care of properly (x86 numbers I sent are typo, > it's not 5m20, it's 5m02). Interesting. I wonder if it's got something to do with the generation of the branch trampolines on ARM, as we have a lot of them on an allyesconfig. Is the 5m20 the total build time for the kernel, the time for rebuilding after a trivial change, or the time to call 'ld.bfd' once? Are you using ld.bfd on x86 or ld.gold? For me ld.gold either works and is really fast, or it crashes, depending on the configuration. I also don't think it supports big-endian ARM (which is what allyesconfig ends up using). Arnd