** Description changed:

  [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")
+    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")
+    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:
+ Backport the following fix from stable-6.6.y:
  
     a8f78680ee6b ("arm64: tlb: Optimize ARM64_WORKAROUND_REPEAT_TLBI")
+ 
+ This required a manual fixup in arch_tlbbatch_should_defer because 6.6.
+ uses cpus_have_const_cap in 6.6, but this is not available in Noble.
+ Corrected to alternative_has_cap_unlikely.
  
  [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.

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2170644

Title:
  arm64: munmap performance regression

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2170644/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to