Re: [PATCH v1 1/2] vdso: Add VDSO_UNALIGNED_PACKED config option for ARMv5

["Arnd Bergmann" <arnd@arndb.de>]

On Tue, Oct 20, 2026, at 08:44, Marc Kleine-Budde wrote:
> On 20.10.2026 00:12:57, Arnd Bergmann wrote:
>> On Mon, Oct 19, 2026, at 22:12, Ian Rogers wrote:
>> > +
>> > +config VDSO_UNALIGNED_PACKED
>> > +	bool
>> > +	default CPU_32v5
>> > +	help
>> > +	  Use packed structs rather than memcpy() in include/vdso/unaligned.h
>> > +	  for unaligned memory accesses. Enabled on ARMv5 where GCC may emit
>> > +	  out-of-line memcpy() calls instead of inlining byte accesses.
>>
>> As explained, I think this misrepresents the problem as Arm specific and
>> isn't the correct method for -munaligned-access targets on Arm, which
>> include CPU_32v3, CPU_32v4 and CPU_32v4T along with CPU_32v5.
>>
>> I still hope we can use a version that just produces the intended code
>> on both -munaligned-access and -mno-unaligned-access targets like the
>> old version did.
>
> FYI: there is the kconfig Symbol HAVE_EFFICIENT_UNALIGNED_ACCESS. Can we
> make use of it?

That would be better, but I still hope we can just get back to the
portable code across all architectures for the in-kernel version.

I have one more request for you: can you check /proc/cpu/alignment
on the system that shows the performance regression with and without
the patch? In your original report, you have shown that Ian's patch
caused the drop in performance and that it caused the added function
calls, but I don't see any sufficiently hot code path that would
actually explain the scale of the regression, unless there is now
also a case where get_unaligned() ends up doing the wrong case and
running into a fixup handler. If this happens, you should see a
nontrivial number of fixups listed in /proc/cpu/alignment. On
a working system, the numbers should all be low but likely nonzero
because there tend to be callers that still lack get_unaligned()
wrappers and just access misaligned pointers directly.

      Arnd