[SRU][N][PATCH 0/1] arm64: munmap performance regression
Krister Johansen
kjlx at templeofstupid.com
Mon Oct 12 23:22:48 UTC 2026
BugLink: https://bugs.launchpad.net/bugs/2170644
[Impact]
Starting with Noble linux-6.8.0-146.146, users on arm64 architectures
began reporting 2-3x performance regressions on workloads that performed
munmap(2) calls in their critical path.
One affected workload was git, which with a large repo containing lots
of packfiles, experienced a 3x increase in system time for fetches
post-upgrade.
This doesn't affect all arm64 implementations equally. When testing
across the Graviton fleet, Neoverse-N1 (6g) and Neoverse-V1 (7g)
observed the impact as a 220-300% regression, whereas Neoverse-V2 (8g)
and Neoverse-V3 (9g) saw something closer to 5%. I haven't had an
opportunity to test Azure or NVIDIA systems for a wider comparison.
Running a build without CONFIG_ARM64_ERRATUM_4118414 restored the
missing performance.
Upon inspection, Ubuntu seems not to have backported the fix from this
patch:
a8f78680ee6b ("arm64: tlb: Optimize ARM64_WORKAROUND_REPEAT_TLBI")
Apply it with CONFIG_ARM64_ERRATUM_4118414 enabled also restored the
missing performance.
This fix was part of LTS 6.6.143 and LTS 6.12.94, which were purportedly
included in 6.8.0-146.146. I tested vanilla builds of 6.12.94 on the
same hardware and further confirmed no regression was present.
This patch appears to have been lost in the shuffle with both the LTS
merge for this release and the inclusion of the fixes for
CVE-2025-10263.
I additionally scanned the 6.6.143 and 6.12.94 patches for other absent
backports and identified the following other candidates as not present:
3c2d42b8ee34 ("mm/memory-failure: fix hugetlb_lock AA deadlock in get_huge_page_for_hwpoison")
8d878059924f ("mm/huge_memory: update file PMD counter before folio_put()")
ba23f58de896 ("mm/migrate: don't call folio_putback_active_hugetlb() on dst hugetlb folio")
2c85c61d1332 ("HID: pass the buffer size to hid_report_raw_event")
165573e41f2f ("tcp: secure_seq: add back ports to TS offset")
fba0510cd626 ("pmdomain: imx: fix OF node refcount")
da3039e91d1f ("ALSA: timer: Forcibly close timer instances at closing")
8473c3a197b5 ("pinctrl: mcp23s08: Initialize mcp->dev and mcp->addr before regmap init")
a7767290e77c ("net/mlx5: Use effective affinity mask for IRQ selection")
2b5ff4db5d7a ("ALSA: seq: dummy: fix UMP event stack overread")
1aee05e814d2 ("erofs: fix use-after-free on sbi->sync_decompress")
I don't have context on whether these omissions are intentional. The
tcp secure_seq patch, for example, makes kabi changes. I opted not to
include the remainders in this list in order to expedite the resolution
of the munmap regression. I can follow-up with a subsequent series for
these other patches, if necessary.
[Fix]
Cherry pick the following fix from stable-6.6.y:
a8f78680ee6b ("arm64: tlb: Optimize ARM64_WORKAROUND_REPEAT_TLBI")
[Test]
Constructed a munmap microbenchmark that unmapped a 7GiB worth of 1MiB
file-backed segments. With ARM64_ERRATUM_4118414 enabled but
optimizations missing observed 200-300% increase on some arm64
platforms. Applied the fix listed above and re-ran the tests and
validated that baseline performance from before ARM64_ERRATUM_4118414
was enabled returned.
[Where problems can occur]
This fix has been in Linux since 7.0. There have been no followup fixes
identifying this patch as problematic with a "Fixes" tag. The
likelihood of problems is low, but if they were to occur it would
involve tlb flushing edge cases which do present as subtle mm errors and
can be quite fiddly to track down.
Mark Rutland (1):
arm64: tlb: Optimize ARM64_WORKAROUND_REPEAT_TLBI
arch/arm64/include/asm/tlbflush.h | 59 ++++++++++++++++++-------------
arch/arm64/kernel/sys_compat.c | 2 +-
arch/arm64/kvm/hyp/nvhe/mm.c | 2 +-
arch/arm64/kvm/hyp/nvhe/tlb.c | 8 ++---
arch/arm64/kvm/hyp/pgtable.c | 2 +-
arch/arm64/kvm/hyp/vhe/tlb.c | 8 ++---
6 files changed, 46 insertions(+), 35 deletions(-)
--
2.43.0
More information about the kernel-team
mailing list