fix(aspacem): raise amd64 managed address ceiling to 1 TiB

[not-matthias]

Raises amd64 aspacem_maxAddr from 128 GiB to 1 TiB so a client can float a 256 GiB MAP_NORESERVE reservation (e.g. snmalloc) under Callgrind instead of getting EINVAL. Scoped to VGP_amd64_linux.

Refs COD-3073

[greptile-apps]

Greptile Summary

This PR bundles two related fixes for CodSpeed's ARM64 CI environment: it raises the amd64 aspacem_maxAddr from 128 GiB to 1 TiB (scoped to VGP_amd64_linux) so that large MAP_NORESERVE allocations are no longer rejected with EINVAL, and extends the /proc/cpuinfo LL/SC-fallback detection to cover Cortex-A72.

• aspacemgr-linux.c: 1 TiB is within the 47-bit amd64 user VA limit; the ENABLE_INNER clamp is correctly applied after the new platform guard.
• m_machine.c: Cortex-A72 detection requires both ARM implementer (0x41) and part (0xd08) to match; false positives are safe-direction.
• CI / bench: New llsc_tzconvert_bench.c fixture in Git LFS is compiled in CI; LFS checkout is already enabled.

Confidence Score: 5/5

Both the address-space ceiling increase and the Cortex-A72 LLSC fallback detection are targeted, well-bounded changes with no regressions for other platforms; safe to merge.

The amd64 aspacem_maxAddr increase to 1 TiB stays well inside the 47-bit user VA limit, and the ENABLE_INNER clamp is preserved. The Cortex-A72 detection adds a compound AND condition that is safe-direction on a false positive. CI additions are consistent with existing patterns and LFS is already enabled.

No files require special attention.

Important Files Changed

Filename	Overview
coregrind/m_aspacemgr/aspacemgr-linux.c	Raises aspacem_maxAddr from 128 GiB to 1 TiB for VGP_amd64_linux only; stays within the 47-bit user VA limit, ENABLE_INNER clamp correctly applied after the new platform guard.
coregrind/m_machine.c	Extends LLSC-fallback detection to include Cortex-A72 (ARM Ltd 0x41 / part 0xd08) alongside existing Cavium check; safe-direction false positives acknowledged in comment.
.github/workflows/codspeed.yml	Adds Build bench fixtures CI step compiling llsc_tzconvert_bench.c from LFS-backed source; LFS already enabled via lfs: true in checkout.
bench/generate_config.py	Adds stress-ng commands and llsc_tzconvert_bench 5000 to benchmark list; follows existing testdata/... path convention.
bench/testdata/llsc_tzconvert_bench.c	New Git LFS pointer for a C benchmark exercising localtime()/__tz_convert() CAS loops; compiled in CI and excluded from git tracking.
.gitignore	Adds compiled llsc_tzconvert_bench binary and bench/pycache/ to .gitignore.

_{Reviews (2): Last reviewed commit: "fix(aspacem): raise amd64 managed addres..." | Re-trigger Greptile}

[codspeed-hq]

Merging this PR will improve performance by 61.09%

⚡ 9 improved benchmarks
✅ 41 untouched benchmarks
🆕 10 new benchmarks
⏩ 80 skipped benchmarks¹

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
⚡	test_valgrind[valgrind.codspeed, stress-ng --cpu 4 --cpu-ops 10, full-no-inline]	20 s	2.9 s	×6.9
⚡	test_valgrind[valgrind.codspeed, stress-ng --cpu 4 --cpu-ops 10, full-with-inline-with-cycle-estimation]	14.6 s	3.5 s	×4.2
⚡	test_valgrind[valgrind.codspeed, stress-ng --cpu 4 --cpu-ops 10, no-inline]	2.1 s	1.8 s	+17.73%
⚡	test_valgrind[valgrind.codspeed, stress-ng --cpu 4 --cpu-ops 10, inline]	2.3 s	2 s	+15.71%
⚡	test_valgrind[valgrind.codspeed, stress-ng --cpu 1 --cpu-ops 10, no-inline]	4.4 s	3.8 s	+15.31%
⚡	test_valgrind[valgrind.codspeed, stress-ng --cpu 4 --cpu-ops 10, cycle-estimation]	2.3 s	2 s	+14.74%
⚡	test_valgrind[valgrind.codspeed, stress-ng --cpu 1 --cpu-ops 10, cycle-estimation]	4.8 s	4.3 s	+12.07%
⚡	test_valgrind[valgrind.codspeed, stress-ng --cpu 4 --cpu-ops 10, full-with-inline]	3.6 s	3.2 s	+11.92%
⚡	test_valgrind[valgrind.codspeed, stress-ng --cpu 1 --cpu-ops 10, full-with-inline-with-cycle-estimation]	9.5 s	8.5 s	+11.59%
🆕	test_valgrind[valgrind.codspeed, testdata/llsc_tzconvert_bench 5000, cycle-estimation]	N/A	792.5 ms	N/A
🆕	test_valgrind[valgrind.codspeed, testdata/llsc_tzconvert_bench 5000, full-no-inline]	N/A	1 s	N/A
🆕	test_valgrind[valgrind.codspeed, testdata/llsc_tzconvert_bench 5000, full-with-inline-with-cycle-estimation]	N/A	1.3 s	N/A
🆕	test_valgrind[valgrind.codspeed, testdata/llsc_tzconvert_bench 5000, full-with-inline]	N/A	1.2 s	N/A
🆕	test_valgrind[valgrind.codspeed, testdata/llsc_tzconvert_bench 5000, inline]	N/A	910.7 ms	N/A
🆕	test_valgrind[valgrind.codspeed, testdata/llsc_tzconvert_bench 5000, no-inline]	N/A	705.9 ms	N/A
🆕	test_valgrind[valgrind-3.25.1, testdata/llsc_tzconvert_bench 5000, full-no-inline]	N/A	1 s	N/A
🆕	test_valgrind[valgrind-3.25.1, testdata/llsc_tzconvert_bench 5000, full-with-inline]	N/A	1.2 s	N/A
🆕	test_valgrind[valgrind-3.25.1, testdata/llsc_tzconvert_bench 5000, inline]	N/A	885.7 ms	N/A
🆕	test_valgrind[valgrind-3.25.1, testdata/llsc_tzconvert_bench 5000, no-inline]	N/A	710.8 ms	N/A

Tip

Curious why this is faster? Comment @codspeedbot explain why this is faster on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing cod-3073-investigate-valgrind-support-for-snmallocs-256-gib (5dc8a71) with master (8a82521)²}

Footnotes

1. 80 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

2. No successful run was found on master (b738cff) during the generation of this report, so 8a82521 was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩