Re: [PATCH] powerpc: Add gpr1 and fpu save/restore functions

----- Original Message -----

From: "Michael Ellerman" <mpe@ellerman.id.au>
To: "Timothy Pearson" <tpearson@raptorengineering.com>, "Segher Boessenkool" <redacted>
Cc: "linuxppc-dev" <redacted>
Sent: Monday, February 12, 2024 11:23:30 PM
Subject: Re: [PATCH] powerpc: Add gpr1 and fpu save/restore functions

Timothy Pearson [off-list ref] writes:

quoted

----- Original Message -----

quoted

From: "Segher Boessenkool" <redacted>
To: "Timothy Pearson" <tpearson@raptorengineering.com>
Cc: "linuxppc-dev" <redacted>
Sent: Monday, February 12, 2024 12:23:22 PM
Subject: Re: [PATCH] powerpc: Add gpr1 and fpu save/restore functions

quoted

On Mon, Feb 12, 2024 at 12:07:03PM -0600, Timothy Pearson wrote:

quoted

quoted

I have done it for *all* architectures some ten years ago.  Never found
any problem.

That makes sense, what I mean by invasive is that we'd need buy-in from the
other
maintainers across all of the affected architectures.  Is that likely to occur?

I don't know.  Here is my PowerPC-specific patch, it's a bit older, it
might not apply cleanly anymore, the changes needed should be obvious
though:


=== 8< ===
commit f16dfa5257eb14549ce22243fb2b465615085134
Author: Segher Boessenkool [off-list ref]
Date:   Sat May 3 03:48:06 2008 +0200

   powerpc: Link vmlinux against libgcc.a

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index b7212b619c52..0a2fac6ffc1c 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile

@@ -158,6 +158,9 @@ core-y                              += arch/powerpc/kernel/

core-$(CONFIG_XMON)            += arch/powerpc/xmon/
core-$(CONFIG_KVM)             += arch/powerpc/kvm/

+LIBGCC := $(shell $(CC) $(KBUILD_CFLAGS) -print-libgcc-file-name)
+libs-y += $(LIBGCC)
+
drivers-$(CONFIG_OPROFILE)     += arch/powerpc/oprofile/

# Default to zImage, override when needed
=== 8< ===

OK.  PowerPC maintainers, how would you prefer to handle this?

I'll take the patch to add the functions for now. We can look into
linking against libgcc as a future cleanup.

Sounds good.

quoted

quoted

quoted

quoted

There are better options than -Os, fwiw.  Some --param's give smaller
*and* faster kernels.  What exactly is best is heavily arch-dependent
though (as well as dependent on the application code, the kernel code in
this case) :-(

I've been through this a few times, and -Os is the only option that makes
things (just barely) fit unfortunately.

-O2 with appropriate inlining tuning beats -Os every day of the week,
in my experience.

On 6.6 it's 24MiB vs 40MiB, O2 vs. Os. :(

What compiler/config etc. are you using for that?

It's the kernel config that buildroot generates for skiroot -- I think a lot of the size difference is in some of the modules that we enable such as amdgpu, but haven't dug too deeply.  Once this firmware release is in beta (and therefore published publicly) I'll send over a link to the configs.

Thanks!