[PATCH] arm64: Avoid eager DVMSync reclaim batches with C1-Pro SME erratum

[Will Deacon]

On Wed, Jun 10, 2026 at 11:37:16AM +0100, Catalin Marinas wrote:
> The C1-Pro SME DVMSync workaround currently samples mm_cpumask() from
> arch_tlbbatch_add_pending(). It requires a DSB after every batched TLBI
> so that the mask read is ordered after the hardware DVMSync, defeating
> much of the reclaim batching benefit.
> 
> Introduce the sme_active_cpus mask tracking which CPUs run in user-space
> with SME enabled and use it for batch flushing instead of accumulating
> the mm_cpumask() of the unmapped pages.
> 
> Fixes: 0baba94a9779 ("arm64: errata: Work around early CME DVMSync acknowledgement")
> Signed-off-by: Catalin Marinas <catalin.marinas at arm.com>
> Cc: Will Deacon <will at kernel.org>
> ---
> 
> The dsb() in arch_tlbbatch_add_pending() -> sme_dvmsync_add_pending()
> did introduce a performance regression for kswapd. This patch restores
> the original behaviour with the barrier only issued when the TLB batch
> is flushed. The trade-off is that the IPIs are now sent to all CPUs
> running with SME enabled at EL0 even if the reclaimed pages do not
> belong to SME tasks. This is acceptable for current SME deployments.
> 
>  arch/arm64/include/asm/tlbbatch.h | 10 ++-----
>  arch/arm64/include/asm/tlbflush.h | 49 +++++--------------------------
>  arch/arm64/kernel/fpsimd.c        | 10 +++++--
>  arch/arm64/kernel/process.c       | 35 ----------------------
>  4 files changed, 17 insertions(+), 87 deletions(-)

Ok, so this partially undoes the work to mitigate the IPI-based DoS
reported by Sashiko, but only for the TLB batching case. The mm_cpumask()
is still used for the unbatched case.

It looks functionally correct to me, but it would be great to see some
Tested-by lines from people who are concerned about the performance...

Will