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

[Michael Ellerman <mpe@ellerman.id.au>]

Timothy Pearson <tpearson@raptorengineering.com> writes:
> ----- Original Message -----
>> From: "Segher Boessenkool" <segher@kernel.crashing.org>
>> To: "Timothy Pearson" <tpearson@raptorengineering.com>
>> Cc: "linuxppc-dev" <linuxppc-dev@lists.ozlabs.org>
>> Sent: Monday, February 12, 2024 12:23:22 PM
>> Subject: Re: [PATCH] powerpc: Add gpr1 and fpu save/restore functions
>
>> On Mon, Feb 12, 2024 at 12:07:03PM -0600, Timothy Pearson wrote:
>>> > 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 <segher@kernel.crashing.org>
>> 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.

>>> > 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?

I see almost no difference, though the defconfig (which uses -O2) is
actually smaller:

$ ls -l vmlinux.Os vmlinux.defconfig
-rwxr-xr-x. 1 michael michael 49936640 Feb 13 16:11 vmlinux.defconfig*
-rwxr-xr-x. 1 michael michael 50108392 Feb 13 16:14 vmlinux.Os*

cheers