All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ardb@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>,
	Masahiro Yamada <masahiroy@kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org,
	Nicolas Schier <nicolas@fjasle.eu>,
	linux-kernel@vger.kernel.org
Cc: Martin KaFai Lau <martin.lau@linux.dev>,
	"open list:BPF JIT for MIPS (32-BIT AND 64-BIT)" 
	<bpf@vger.kernel.org>
Subject: Re: [PATCH] arm64: remove special treatment for the link order of head.o
Date: Fri, 24 Mar 2023 12:33:40 +0100	[thread overview]
Message-ID: <CAMj1kXHvfHwQFX1SKbUvpHWOr3+i7Tp5Hod-_jZE4hDHZmmRZg@mail.gmail.com> (raw)
In-Reply-To: <ZBzAp457rrO52FPy@aurel32.net>

(cc BTF list and maintainer)

On Thu, 23 Mar 2023 at 22:12, Aurelien Jarno <aurelien@aurel32.net> wrote:
>
> Hi,
>
> On 2023-03-22 15:51, Ard Biesheuvel wrote:
> > On Tue, 21 Mar 2023 at 23:26, Aurelien Jarno <aurelien@aurel32.net> wrote:
> > >
> > > Hi,
> > >
> > > On 2022-10-13 08:35, Masahiro Yamada wrote:
> > > > In the previous discussion (see the Link tag), Ard pointed out that
> > > > arm/arm64/kernel/head.o does not need any special treatment - the only
> > > > piece that must appear right at the start of the binary image is the
> > > > image header which is emitted into .head.text.
> > > >
> > > > The linker script does the right thing to do. The build system does
> > > > not need to manipulate the link order of head.o.
> > > >
> > > > Link: https://lore.kernel.org/lkml/CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-CG=EuA@mail.gmail.com/
> > > > Suggested-by: Ard Biesheuvel <ardb@kernel.org>
> > > > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> > > > ---
> > > >
> > > >  scripts/head-object-list.txt | 1 -
> > > >  1 file changed, 1 deletion(-)
> > > >
> > > > diff --git a/scripts/head-object-list.txt b/scripts/head-object-list.txt
> > > > index b16326a92c45..f226e45e3b7b 100644
> > > > --- a/scripts/head-object-list.txt
> > > > +++ b/scripts/head-object-list.txt
> > > > @@ -15,7 +15,6 @@ arch/alpha/kernel/head.o
> > > >  arch/arc/kernel/head.o
> > > >  arch/arm/kernel/head-nommu.o
> > > >  arch/arm/kernel/head.o
> > > > -arch/arm64/kernel/head.o
> > > >  arch/csky/kernel/head.o
> > > >  arch/hexagon/kernel/head.o
> > > >  arch/ia64/kernel/head.o
> > >
> > > This patch causes a significant increase of the arch/arm64/boot/Image
> > > size. For instance the generic arm64 Debian kernel went from 31 to 39 MB
> > > after this patch has been applied to the 6.1 stable tree.
> > >
> > > In turn this causes issues with some bootloaders, for instance U-Boot on
> > > a Raspberry Pi limits the kernel size to 36 MB.
> > >
> >
> > I cannot reproduce this with mainline
> >
> > With the patch
> >
> > $ size vmlinux
> >    text    data     bss     dec     hex filename
> > 24567309 14752630 621680 39941619 26175f3 vmlinux
> >
> > With the patch reverted
> >
> > $ size vmlinux
> >    text    data     bss     dec     hex filename
> > 24567309 14752694 621680 39941683 2617633 vmlinux
>
> I have tried with the current mainline, this is what I get, using GCC 12.2.0
> and binutils 2.40:
>
>    text    data     bss     dec     hex filename
> 32531655        8192996  621968 41346619        276e63b vmlinux.orig
> 25170610        8192996  621968 33985574        2069426 vmlinux.revert
>
> > It would help to compare the resulting vmlinux ELF images from both
> > builds to see where the extra space is being allocated
>
> At a first glance, it seems the extra space is allocated in the BTF
> section. I have uploaded the resulting files as well as the config file
> I used there:
> https://temp.aurel32.net/linux-arm64-size-head.o.tar.gz
>

Indeed. So we go from

  [15] .BTF              PROGBITS         ffff8000091d1ff4  011e1ff4
       00000000005093d6  0000000000000000   A       0     0     1

to

  [15] .BTF              PROGBITS         ffff8000091d1ff4  011e1ff4
       0000000000c0e5eb  0000000000000000   A       0     0     1

i.e, from 5 MiB to 12+ MiB of BTF metadata.

To me, it is not clear at all how one would be related to the other,
so it will leave it to the Kbuild and BTF experts to chew on this one.

WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ardb@kernel.org>
To: Ard Biesheuvel <ardb@kernel.org>,
	Masahiro Yamada <masahiroy@kernel.org>,
	 Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	 linux-arm-kernel@lists.infradead.org,
	linux-arch@vger.kernel.org,  Nicolas Schier <nicolas@fjasle.eu>,
	linux-kernel@vger.kernel.org
Cc: Martin KaFai Lau <martin.lau@linux.dev>,
	 "open list:BPF JIT for MIPS (32-BIT AND 64-BIT)"
	<bpf@vger.kernel.org>
Subject: Re: [PATCH] arm64: remove special treatment for the link order of head.o
Date: Fri, 24 Mar 2023 12:33:40 +0100	[thread overview]
Message-ID: <CAMj1kXHvfHwQFX1SKbUvpHWOr3+i7Tp5Hod-_jZE4hDHZmmRZg@mail.gmail.com> (raw)
In-Reply-To: <ZBzAp457rrO52FPy@aurel32.net>

(cc BTF list and maintainer)

On Thu, 23 Mar 2023 at 22:12, Aurelien Jarno <aurelien@aurel32.net> wrote:
>
> Hi,
>
> On 2023-03-22 15:51, Ard Biesheuvel wrote:
> > On Tue, 21 Mar 2023 at 23:26, Aurelien Jarno <aurelien@aurel32.net> wrote:
> > >
> > > Hi,
> > >
> > > On 2022-10-13 08:35, Masahiro Yamada wrote:
> > > > In the previous discussion (see the Link tag), Ard pointed out that
> > > > arm/arm64/kernel/head.o does not need any special treatment - the only
> > > > piece that must appear right at the start of the binary image is the
> > > > image header which is emitted into .head.text.
> > > >
> > > > The linker script does the right thing to do. The build system does
> > > > not need to manipulate the link order of head.o.
> > > >
> > > > Link: https://lore.kernel.org/lkml/CAMj1kXH77Ja8bSsq2Qj8Ck9iSZKw=1F8Uy-uAWGVDm4-CG=EuA@mail.gmail.com/
> > > > Suggested-by: Ard Biesheuvel <ardb@kernel.org>
> > > > Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
> > > > ---
> > > >
> > > >  scripts/head-object-list.txt | 1 -
> > > >  1 file changed, 1 deletion(-)
> > > >
> > > > diff --git a/scripts/head-object-list.txt b/scripts/head-object-list.txt
> > > > index b16326a92c45..f226e45e3b7b 100644
> > > > --- a/scripts/head-object-list.txt
> > > > +++ b/scripts/head-object-list.txt
> > > > @@ -15,7 +15,6 @@ arch/alpha/kernel/head.o
> > > >  arch/arc/kernel/head.o
> > > >  arch/arm/kernel/head-nommu.o
> > > >  arch/arm/kernel/head.o
> > > > -arch/arm64/kernel/head.o
> > > >  arch/csky/kernel/head.o
> > > >  arch/hexagon/kernel/head.o
> > > >  arch/ia64/kernel/head.o
> > >
> > > This patch causes a significant increase of the arch/arm64/boot/Image
> > > size. For instance the generic arm64 Debian kernel went from 31 to 39 MB
> > > after this patch has been applied to the 6.1 stable tree.
> > >
> > > In turn this causes issues with some bootloaders, for instance U-Boot on
> > > a Raspberry Pi limits the kernel size to 36 MB.
> > >
> >
> > I cannot reproduce this with mainline
> >
> > With the patch
> >
> > $ size vmlinux
> >    text    data     bss     dec     hex filename
> > 24567309 14752630 621680 39941619 26175f3 vmlinux
> >
> > With the patch reverted
> >
> > $ size vmlinux
> >    text    data     bss     dec     hex filename
> > 24567309 14752694 621680 39941683 2617633 vmlinux
>
> I have tried with the current mainline, this is what I get, using GCC 12.2.0
> and binutils 2.40:
>
>    text    data     bss     dec     hex filename
> 32531655        8192996  621968 41346619        276e63b vmlinux.orig
> 25170610        8192996  621968 33985574        2069426 vmlinux.revert
>
> > It would help to compare the resulting vmlinux ELF images from both
> > builds to see where the extra space is being allocated
>
> At a first glance, it seems the extra space is allocated in the BTF
> section. I have uploaded the resulting files as well as the config file
> I used there:
> https://temp.aurel32.net/linux-arm64-size-head.o.tar.gz
>

Indeed. So we go from

  [15] .BTF              PROGBITS         ffff8000091d1ff4  011e1ff4
       00000000005093d6  0000000000000000   A       0     0     1

to

  [15] .BTF              PROGBITS         ffff8000091d1ff4  011e1ff4
       0000000000c0e5eb  0000000000000000   A       0     0     1

i.e, from 5 MiB to 12+ MiB of BTF metadata.

To me, it is not clear at all how one would be related to the other,
so it will leave it to the Kbuild and BTF experts to chew on this one.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2023-03-24 11:34 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-12 23:35 [PATCH] arm64: remove special treatment for the link order of head.o Masahiro Yamada
2022-10-12 23:35 ` Masahiro Yamada
2022-10-13 17:07 ` Nicolas Schier
2022-10-13 17:07   ` Nicolas Schier
2022-11-07 19:08 ` Will Deacon
2022-11-07 19:08   ` Will Deacon
2023-03-21 22:26 ` Aurelien Jarno
2023-03-21 22:26   ` Aurelien Jarno
2023-03-22 14:51   ` Ard Biesheuvel
2023-03-22 14:51     ` Ard Biesheuvel
2023-03-23 21:12     ` Aurelien Jarno
2023-03-23 21:12       ` Aurelien Jarno
2023-03-24 11:33       ` Ard Biesheuvel [this message]
2023-03-24 11:33         ` Ard Biesheuvel
2023-03-24 23:33         ` Alexei Starovoitov
2023-03-24 23:33           ` Alexei Starovoitov
2023-03-28  4:05           ` Andrii Nakryiko
2023-03-28  4:05             ` Andrii Nakryiko
2023-03-25  6:05         ` Masahiro Yamada
2023-03-25  6:05           ` Masahiro Yamada
2023-03-25 11:42           ` Masahiro Yamada
2023-03-25 11:42             ` Masahiro Yamada
2023-03-28 10:33             ` Eduard Zingerman
2023-03-28 10:33               ` Eduard Zingerman
2023-03-28 19:52               ` Arnaldo Carvalho de Melo
2023-03-28 19:52                 ` Arnaldo Carvalho de Melo
2023-04-29  7:29                 ` Aurelien Jarno
2023-04-29  7:29                   ` Aurelien Jarno

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=CAMj1kXHvfHwQFX1SKbUvpHWOr3+i7Tp5Hod-_jZE4hDHZmmRZg@mail.gmail.com \
    --to=ardb@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.lau@linux.dev \
    --cc=masahiroy@kernel.org \
    --cc=nicolas@fjasle.eu \
    --cc=will@kernel.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.