From: Nicholas Piggin <npiggin@gmail.com>
To: Oliver <oohall@gmail.com>
Cc: linux-mips@linux-mips.org, linux-sh@vger.kernel.org,
Benjamin Herrenschmidt <benh@kernel.crashing.org>,
Linus Walleij <linus.walleij@linaro.org>,
Will Deacon <will.deacon@arm.com>,
Paul Mackerras <paulus@samba.org>,
Michael Ellerman <mpe@ellerman.id.au>,
"James E.J. Bottomley" <jejb@parisc-linux.org>,
Christoph Hellwig <hch@infradead.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Matt Turner <mattst88@gmail.com>,
Eugeniy Paltsev <Eugeniy.Paltsev@synopsys.com>,
uclinux-h8-devel@lists.sourceforge.jp,
Vladimir Murzin <vladimir.murzin@arm.com>,
Marc Zyngier <marc.zyngier@arm.com>,
adi-buildroot-devel@lists.sourceforge.net,
Al Viro <viro@zeniv.linux.org.uk>,
Thomas Gleixner <tglx@linutronix.de>,
Richard Henderson <rth@twiddle.net>,
linux-cris-kernel@axis.com,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
linux-kernel@vger.kerne
Subject: Re: [PATCH] Extract initrd free logic from arch-specific code.
Date: Thu, 29 Mar 2018 10:23:33 +1000 [thread overview]
Message-ID: <20180329102333.6aa542b9@roar.ozlabs.ibm.com> (raw)
In-Reply-To: <CAOSf1CG8gQjoL5rDMRMcZp=D8jBEQ9JBSG68=CiXnitC+4Kjvg@mail.gmail.com>
On Thu, 29 Mar 2018 09:37:52 +1100
Oliver <oohall@gmail.com> wrote:
> On Thu, Mar 29, 2018 at 9:14 AM, Russell King - ARM Linux
> <linux@armlinux.org.uk> wrote:
> > On Wed, Mar 28, 2018 at 02:04:22PM -0500, Rob Landley wrote:
> >>
> >>
> >> On 03/28/2018 11:48 AM, Russell King - ARM Linux wrote:
> >> > On Wed, Mar 28, 2018 at 10:58:51AM -0500, Rob Landley wrote:
> >> >> On 03/28/2018 10:26 AM, Shea Levy wrote:
> >> >>> Now only those architectures that have custom initrd free requirements
> >> >>> need to define free_initrd_mem.
> >> >> ...
> >> >>> --- a/arch/arc/mm/init.c
> >> >>> +++ b/arch/arc/mm/init.c
> >> >>> @@ -229,10 +229,3 @@ void __ref free_initmem(void)
> >> >>> {
> >> >>> free_initmem_default(-1);
> >> >>> }
> >> >>> -
> >> >>> -#ifdef CONFIG_BLK_DEV_INITRD
> >> >>> -void __init free_initrd_mem(unsigned long start, unsigned long end)
> >> >>> -{
> >> >>> - free_reserved_area((void *)start, (void *)end, -1, "initrd");
> >> >>> -}
> >> >>> -#endif
> >> >>> diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
> >> >>> index 3f972e83909b..19d1c5594e2d 100644
> >> >>> --- a/arch/arm/Kconfig
> >> >>> +++ b/arch/arm/Kconfig
> >> >>> @@ -47,6 +47,7 @@ config ARM
> >> >>> select HARDIRQS_SW_RESEND
> >> >>> select HAVE_ARCH_AUDITSYSCALL if (AEABI && !OABI_COMPAT)
> >> >>> select HAVE_ARCH_BITREVERSE if (CPU_32v7M || CPU_32v7) && !CPU_32v6
> >> >>> + select HAVE_ARCH_FREE_INITRD_MEM
> >> >>> select HAVE_ARCH_JUMP_LABEL if !XIP_KERNEL && !CPU_ENDIAN_BE32 && MMU
> >> >>> select HAVE_ARCH_KGDB if !CPU_ENDIAN_BE32 && MMU
> >> >>> select HAVE_ARCH_MMAP_RND_BITS if MMU
> >> >>
> >> >> Isn't this why weak symbols were invented?
> >> >
> >> > Weak symbols means that we end up with both the weakly-referenced code
> >> > and the arch code in the kernel image. That's fine if the weak code
> >> > is small.
> >>
> >> The kernel's been able to build with link time garbage collection since 2016:
> >>
> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=b67067f1176d
> >>
> >> Wouldn't that remove the unused one?
> >
> > Probably, if anyone bothered to use that, which they don't.
> >
> > LD_DEAD_CODE_DATA_ELIMINATION is a symbol without a prompt, and from
> > what I can see, nothing selects it. Therefore, the symbol is always
> > disabled, and so the feature never gets used in mainline kernels.
> >
> > Brings up the obvious question - why is it there if it's completely
> > unused? (Maybe to cause confusion, and allowing a justification
> > for __weak ?)
Well weak symbols have been used long before it was added.
> IIRC Nick had some patches to do the arch enablement for powerpc, but
> I'm not sure what happened to them though. I suspect it just fell down
> Nick's ever growing TODO list.
Yeah I had started some patches for powerpc and x86 that have ended up
on the back burner. There's been some MIPS people playing with it too.
For the kernel, LD_DEAD_CODE_DATA_ELIMINATION is not great. It can save
a little, but you get issues like any exception table entry or bug table
entry in a function will create a reference back to the function, so the
linker can't trim it away even if nothing else references it.
I'll try to take another look at it within the next few months and
remove it if I can't make progress.
Nicolas Pitre has been doing some much better work on dead code using
real LTO.
Thanks,
Nick
next prev parent reply other threads:[~2018-03-29 0:23 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180325221853.10839-1-shea@shealevy.com>
2018-03-28 15:26 ` [PATCH] Extract initrd free logic from arch-specific code Shea Levy
2018-03-28 15:58 ` Rob Landley
2018-03-28 16:04 ` Shea Levy
2018-03-28 16:48 ` Russell King - ARM Linux
2018-03-28 19:04 ` Rob Landley
2018-03-28 22:14 ` Russell King - ARM Linux
2018-03-28 22:37 ` Oliver
2018-03-29 0:23 ` Nicholas Piggin [this message]
2018-03-29 15:27 ` Russell King - ARM Linux
2018-03-29 15:43 ` Geert Uytterhoeven
2018-03-29 15:58 ` Russell King - ARM Linux
2018-03-29 16:53 ` Marc Zyngier
2018-03-29 17:32 ` Russell King - ARM Linux
2018-03-29 17:53 ` Marc Zyngier
2018-03-29 17:43 ` Rob Landley
2018-03-29 16:39 ` Rob Landley
2018-03-29 17:31 ` Russell King - ARM Linux
2018-03-28 16:55 ` Kees Cook
2018-03-29 1:12 ` Wei Yang
2018-03-30 1:43 ` kbuild test robot
2018-03-30 3:16 ` kbuild test robot
2018-03-30 11:15 ` Ingo Molnar
2018-04-01 15:05 ` Shea Levy
2018-04-02 5:59 ` Ingo Molnar
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=20180329102333.6aa542b9@roar.ozlabs.ibm.com \
--to=npiggin@gmail.com \
--cc=Eugeniy.Paltsev@synopsys.com \
--cc=adi-buildroot-devel@lists.sourceforge.net \
--cc=benh@kernel.crashing.org \
--cc=catalin.marinas@arm.com \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=hch@infradead.org \
--cc=jejb@parisc-linux.org \
--cc=linus.walleij@linaro.org \
--cc=linux-cris-kernel@axis.com \
--cc=linux-kernel@vger.kerne \
--cc=linux-mips@linux-mips.org \
--cc=linux-sh@vger.kernel.org \
--cc=marc.zyngier@arm.com \
--cc=mattst88@gmail.com \
--cc=mpe@ellerman.id.au \
--cc=oohall@gmail.com \
--cc=paulus@samba.org \
--cc=rth@twiddle.net \
--cc=tglx@linutronix.de \
--cc=uclinux-h8-devel@lists.sourceforge.jp \
--cc=viro@zeniv.linux.org.uk \
--cc=vladimir.murzin@arm.com \
--cc=will.deacon@arm.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).