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

[Marc Kleine-Budde]

On 20.10.2026 10:24:51, Arnd Bergmann wrote:
> 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?

I asked Stefan Kerkmann (who wrote the original regression report) the
same question, but we haven't had time for it yet. We'll get around to
it.

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

Don't underestimate the overhead of function calls on those old CPUs
with tiny I-caches.

Little side note: IIRC, even on ARMv7 you can measure the performance
overhead of the built-in, but disabled, function tracer.

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

regards,
Marc

-- 
Pengutronix e.K.                 | Marc Kleine-Budde          |
Embedded Linux                   | https://www.pengutronix.de |
Vertretung Nürnberg              | Phone: +49-5121-206917-129 |
Amtsgericht Hildesheim, HRA 2686 | Fax:   +49-5121-206917-9   |

Attachment: signature.asc
Description: PGP signature