Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1460476 > unrolled thread

Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 -  next-20160729 build failures Nicholas Piggin <npiggin@gmail.com> - 2016-08-11 14:50 +0200
    Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures Arnd Bergmann <arnd@arndb.de> - 2016-08-11 15:10 +0200
      Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 -  next-20160729 build failures Nicholas Piggin <npiggin@gmail.com> - 2016-08-11 15:20 +0200
        [TESTING] kbuild: link drivers subdirectories separately Arnd Bergmann <arnd@arndb.de> - 2016-08-11 16:00 +0200
          Re: [TESTING] kbuild: link drivers subdirectories separately Arnd Bergmann <arnd@arndb.de> - 2016-08-11 17:50 +0200

#1460476 — Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures

On Wed, 03 Aug 2016 22:13:28 +0200
Arnd Bergmann <arnd@arndb.de> wrote:

> On Wednesday, August 3, 2016 2:44:29 PM CEST Segher Boessenkool wrote:
> > Hi Arnd,
> > 
> > On Wed, Aug 03, 2016 at 08:52:48PM +0200, Arnd Bergmann wrote:  
> > > From my first look, it seems that all of lib/*.o is now getting linked
> > > into vmlinux, while we traditionally leave out everything from lib/
> > > that is not referenced.
> > > 
> > > I also see a noticeable overhead in link time, the numbers are for
> > > a cache-hot rebuild after a successful allyesconfig build, using a
> > > 24-way Opteron@2.5Ghz, just relinking vmlinux:
> > > 
> > > $ time make skj30 vmlinux # before
> > > real	2m8.092s
> > > user	3m41.008s
> > > sys	0m48.172s
> > > 
> > > $ time make skj30 vmlinux # after
> > > real	4m10.189s
> > > user	5m43.804s
> > > sys	0m52.988s  
> > 
> > Is it better when using rcT instead of rcsT?  
> 
> It seems to be noticeably better for the clean rebuild case, though
> not as good as the original:
> 
> real	3m34.015s
> user	5m7.104s
> sys	0m49.172s
> 
> I've also tried now with my own patch applied as well (linking
> each drivers/*/built-in.o into vmlinux rather than having them
> linked into drivers/built-in.o first), but that makes no
> difference.

I just want to come back to this, because I've subbmitted the thin
archives kbuild patch, I wanted to make sure we're doing okay on
ARM/ARM64. I cross compiled with my laptop.

For ARM64 allyesconfig:

After building then removing all built-in.o then rebuilding vmlinux:
inclink
time make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8 vmlinux
real    1m18.977s
user    2m14.512s
sys     0m29.704s

thinarc
time make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8 vmlinux
real    1m18.433s
user    2m6.128s
sys     0m28.372s


Final ld time
inclink
real    0m4.005s
user    0m3.464s
sys     0m0.536s

thinarc
real    0m5.841s
user    0m4.916s
sys     0m0.916s


Build directory size is of course much better (3953MB vs 5519MB).


For ARM, defconfig

After building then removing all built-in.o then rebuilding vmlinux:
inclink
real	0m19.593s
user	0m22.372s
sys	0m6.428s

thinarc
real	0m18.919s
user	0m21.924s
sys	0m6.400s


Final ld time
inclink
real	0m0.378s
user	0m0.304s
sys	0m0.076s

thinarc
real    0m0.894s
user    0m0.684s
sys     0m0.200s

For both cases final link gets slower with thin archives. I guess there is some
per-file overhead but I thought with --whole-archive it should not be that much
slower. Still, overall time for main ar/ld phases comes out about the same in
the end so I don't think it's too much problem. Unless ARM blows up significantly
worse with a bigger config.

Linking with thin archives takes significantly more time in bfd hash lookup code.
I haven't dug much further yet.

Thanks,
Nick

[toc] | [next] | [standalone]

#1460498 — Re: powerpc allyesconfig / allmodconfig linux-next next-20160729 - next-20160729 build failures

On Thursday, August 11, 2016 10:43:20 PM CEST Nicholas Piggin wrote:
> On Wed, 03 Aug 2016 22:13:28 +0200
> Arnd Bergmann <arnd@arndb.de> wrote:
> 
> > On Wednesday, August 3, 2016 2:44:29 PM CEST Segher Boessenkool wrote:
> > > Hi Arnd,
> > > 
> > > On Wed, Aug 03, 2016 at 08:52:48PM +0200, Arnd Bergmann wrote:  
> > > > From my first look, it seems that all of lib/*.o is now getting linked
> > > > into vmlinux, while we traditionally leave out everything from lib/
> > > > that is not referenced.
> > > > 
> > > > I also see a noticeable overhead in link time, the numbers are for
> > > > a cache-hot rebuild after a successful allyesconfig build, using a
> > > > 24-way Opteron@2.5Ghz, just relinking vmlinux:
> > > > 
> > > > $ time make skj30 vmlinux # before
> > > > real	2m8.092s
> > > > user	3m41.008s
> > > > sys	0m48.172s
> > > > 
> > > > $ time make skj30 vmlinux # after
> > > > real	4m10.189s
> > > > user	5m43.804s
> > > > sys	0m52.988s  
> > > 
> > > Is it better when using rcT instead of rcsT?  
> > 
> > It seems to be noticeably better for the clean rebuild case, though
> > not as good as the original:
> > 
> > real	3m34.015s
> > user	5m7.104s
> > sys	0m49.172s
> > 
> > I've also tried now with my own patch applied as well (linking
> > each drivers/*/built-in.o into vmlinux rather than having them
> > linked into drivers/built-in.o first), but that makes no
> > difference.
> 
> I just want to come back to this, because I've subbmitted the thin
> archives kbuild patch, I wanted to make sure we're doing okay on
> ARM/ARM64. I cross compiled with my laptop.
> 
> For ARM64 allyesconfig:
> 
> After building then removing all built-in.o then rebuilding vmlinux:
> inclink
> time make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8 vmlinux
> real    1m18.977s
> user    2m14.512s
> sys     0m29.704s
> 
> thinarc
> time make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j8 vmlinux
> real    1m18.433s
> user    2m6.128s
> sys     0m28.372s
> 
> 
> Final ld time
> inclink
> real    0m4.005s
> user    0m3.464s
> sys     0m0.536s
> 
> thinarc
> real    0m5.841s
> user    0m4.916s
> sys     0m0.916s
> 
> 
> Build directory size is of course much better (3953MB vs 5519MB).

Ok, looks great. Some downsides and some upsides here, but overall
I think this is a win.

> 
> For ARM, defconfig
> 
> After building then removing all built-in.o then rebuilding vmlinux:
> inclink
> real	0m19.593s
> user	0m22.372s
> sys	0m6.428s
> 
> thinarc
> real	0m18.919s
> user	0m21.924s
> sys	0m6.400s
> 
> 
> Final ld time
> inclink
> real	0m0.378s
> user	0m0.304s
> sys	0m0.076s
> 
> thinarc
> real    0m0.894s
> user    0m0.684s
> sys     0m0.200s

This also still seems fine.

> For both cases final link gets slower with thin archives. I guess there is some
> per-file overhead but I thought with --whole-archive it should not be that much
> slower. Still, overall time for main ar/ld phases comes out about the same in
> the end so I don't think it's too much problem. Unless ARM blows up significantly
> worse with a bigger config.

Unfortunately I think it does. I haven't tried your latest series yet,
but I think the total time for removing built-in.o and relinking went
up from around 4 minutes (already way too much) to 18 minutes for me.

> Linking with thin archives takes significantly more time in bfd hash lookup code.
> I haven't dug much further yet.

Can you try the ARM allyesconfig with thin archives? I'll follow up with two
patches: one to get ARM to link without thin archives, and one that I used
to get --gc-sections to work.

	Arnd

[toc] | [prev] | [next] | [standalone]

#1460512

On Thu, 11 Aug 2016 15:04:00 +0200
Arnd Bergmann <arnd@arndb.de> wrote:

> On Thursday, August 11, 2016 10:43:20 PM CEST Nicholas Piggin wrote:
> > On Wed, 03 Aug 2016 22:13:28 +0200

> > Final ld time
> > inclink
> > real	0m0.378s
> > user	0m0.304s
> > sys	0m0.076s
> > 
> > thinarc
> > real    0m0.894s
> > user    0m0.684s
> > sys     0m0.200s  
> 
> This also still seems fine.
> 
> > For both cases final link gets slower with thin archives. I guess there is some
> > per-file overhead but I thought with --whole-archive it should not be that much
> > slower. Still, overall time for main ar/ld phases comes out about the same in
> > the end so I don't think it's too much problem. Unless ARM blows up significantly
> > worse with a bigger config.  
> 
> Unfortunately I think it does. I haven't tried your latest series yet,
> but I think the total time for removing built-in.o and relinking went
> up from around 4 minutes (already way too much) to 18 minutes for me.
> 
> > Linking with thin archives takes significantly more time in bfd hash lookup code.
> > I haven't dug much further yet.  
> 
> Can you try the ARM allyesconfig with thin archives? I'll follow up with two
> patches: one to get ARM to link without thin archives, and one that I used
> to get --gc-sections to work.

Okay send them over, I'll try digging into it. There is not much kbuild
code to maintain so we don't have to switch every arch. It would be nice
to though.

Thanks,
Nick

[toc] | [prev] | [next] | [standalone]

#1460539 — [TESTING] kbuild: link drivers subdirectories separately

On ARM, relative branches between functions can not span more than 32MB,
which limits the size of an ELF section. In the final link, the linker
will introduce trampolines that perform long calls to avoid the limit,
and during a recursive link, trampolines are added within the section.

However, this does not work for cross-section branches when the source
section is already larger than 32MB because there is no longer space
to put the trampoline.

We are unable to build an allyesconfig kernel on ARM because the
.text section in drivers/built-in.o has that problem.

This patch avoids it by linking drivers/*/built-in.o directly into
vmlinux.o, rather than first linking them into drivers/built-in.o.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
This patch gets allyesconfig to work for me on ARM. We have previously
decided that this is too ugly, but you can use it for comparing the
link times.

diff --git a/Makefile b/Makefile
index 2eae4bab0d9b..091ca3a3015b 100644
--- a/Makefile
+++ b/Makefile
@@ -557,13 +557,6 @@ scripts: scripts_basic include/config/auto.conf include/config/tristate.conf \
 	 asm-generic gcc-plugins
 	$(Q)$(MAKE) $(build)=$(@)
 
-# Objects we will link into vmlinux / subdirs we need to visit
-init-y		:= init/
-drivers-y	:= drivers/ sound/ firmware/
-net-y		:= net/
-libs-y		:= lib/
-core-y		:= usr/
-virt-y		:= virt/
 endif # KBUILD_EXTMOD
 
 ifeq ($(dot-config),1)
@@ -584,6 +577,20 @@ $(KCONFIG_CONFIG) include/config/auto.conf.cmd: ;
 # we execute the config step to be sure to catch updated Kconfig files
 include/config/%.conf: $(KCONFIG_CONFIG) include/config/auto.conf.cmd
 	$(Q)$(MAKE) -f $(srctree)/Makefile silentoldconfig
+
+# Objects we will link into vmlinux / subdirs we need to visit
+init-y		:= init/
+net-y		:= net/
+libs-y		:= lib/
+core-y		:= usr/
+virt-y		:= virt/
+
+# split out objects from drivers to avoid recursively linking large .o files
+include drivers/Makefile
+drivers-y	:= $(addprefix drivers/,$(obj-y) $(obj-m))
+drivers-y	+= sound/ firmware/
+obj-y		:=
+
 else
 # external modules needs include/generated/autoconf.h and include/config/auto.conf
 # but do not care if they are up-to-date. Use auto.conf to trigger the test
diff --git a/drivers/Makefile b/drivers/Makefile
index 9cfa547d67ce..38848742db1f 100644
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -95,10 +95,7 @@ obj-$(CONFIG_ATA_OVER_ETH)	+= block/aoe/
 obj-$(CONFIG_PARIDE) 		+= block/paride/
 obj-$(CONFIG_TC)		+= tc/
 obj-$(CONFIG_UWB)		+= uwb/
-obj-$(CONFIG_USB_PHY)		+= usb/
-obj-$(CONFIG_USB)		+= usb/
-obj-$(CONFIG_PCI)		+= usb/
-obj-$(CONFIG_USB_GADGET)	+= usb/
+obj-y				+= usb/
 obj-$(CONFIG_SERIO)		+= input/serio/
 obj-$(CONFIG_GAMEPORT)		+= input/gameport/
 obj-$(CONFIG_INPUT)		+= input/
@@ -137,7 +134,8 @@ obj-$(CONFIG_PPC_PS3)		+= ps3/
 obj-$(CONFIG_OF)		+= of/
 obj-$(CONFIG_SSB)		+= ssb/
 obj-$(CONFIG_BCMA)		+= bcma/
-obj-y				+= vhost/
+obj-$(CONFIG_VHOST_RING)	+= vhost/
+obj-$(CONFIG_VHOST)		+= vhost/
 obj-$(CONFIG_VLYNQ)		+= vlynq/
 obj-$(CONFIG_STAGING)		+= staging/
 obj-y				+= platform/

[toc] | [prev] | [next] | [standalone]

#1460630 — Re: [TESTING] kbuild: link drivers subdirectories separately

On Thursday, August 11, 2016 3:49:03 PM CEST Arnd Bergmann wrote:
> @@ -137,7 +134,8 @@ obj-$(CONFIG_PPC_PS3)               += ps3/
>  obj-$(CONFIG_OF)               += of/
>  obj-$(CONFIG_SSB)              += ssb/
>  obj-$(CONFIG_BCMA)             += bcma/
> -obj-y                          += vhost/
> +obj-$(CONFIG_VHOST_RING)       += vhost/
> +obj-$(CONFIG_VHOST)            += vhost/
>  obj-$(CONFIG_VLYNQ)            += vlynq/
>  obj-$(CONFIG_STAGING)          += staging/
>  obj-y                          += platform/
> 

This hunk should have been the other way round to apply and work correctly,
I mixed up the number of reverts I had on my tree before it.

	Arnd

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web