[PATCH 0/6] arm64: alternatives: switch most used alternatives to callbacks

Ada Couprie Diaz ada.coupriediaz at arm.com
Tue Oct 6 10:30:21 PDT 2026


Hi Catalin,

On 06/10/2026 17:28, Catalin Marinas wrote:
> Hi Ada,
>
> On Mon, Sep 28, 2026 at 02:30:28PM +0100, Ada Couprie Diaz wrote:
>> All numbers are on v7.3-rc4 building defconfig with GCC 13.3.0.
>> Only the patches mentioned are applied on each line.
>>
>> |   Patches    |  Size (B) |	|    Patch    | Size (B) |
>> | Base vmlinux | 172826400 |	|  Base Image | 52374016 |
>> |          1-3 |    -71672 |	|         1-3 |   -65536 |
>> |            4 |    -71704 |    |           4 |   -65536 |
>> |          1-4 |    -64712 |	|         1-4 |   -65536 |
>> |          5-6 |    +68008 |	|         5-6 |       -0 |
>> |  All patches |    + 3240 |    | All patches |   -65536 |
>>
>> The impact on alternatives is two-fold :
>> 1. As expected, all alternatives for the two I/O workarounds and
>>     97% of the `ARM64_HAS_VIRT_HOST_EXTN` alternatives are converted to
>>     callbacks, saving 85848 bytes (20 pages).
>> 2. The raw number of alternatives *increases* by about 3% (250 new entries)
> TBH, I don't think the saving is worth the additional complexity.

Fair, I did expect it a bit but wanted to share if it could be useful.

> I wonder, could we instead move the replacement instructions to a
> separate section we can drop after patching? I can see x86 uses a
> separate .altinstr_replacement. Not sure what restrictions we have on
> arm64, e.g. if it's placed too far.

I think given the amount of alternatives we have now, there was some
distance issue, but I don't have the exact details. I can look into it !

> That said, are some of the other patches worth picking up as cleanups?

Mh, I think patches 1 and 5 are nice small cleanups by themselves,
patch 2 is less obviously useful as-is but is a start on making the
insn framework safer to use for patching (which is not really reasonable
to tackle in one go anyway).

Thanks Catalin,
Kind regards
Ada




More information about the linux-arm-kernel mailing list