> On Sep 15, 2026, at 10:51 AM, Nathan Bossart <[email protected]> wrote:
>
> On Tue, Sep 15, 2026 at 11:46:23AM +0000, Salvatore Dipietro wrote:
>> I'd like to propose backporting this commit 3d0b4b1068 ("Use a
>> non-locking initial test in TAS_SPIN on AArch64.", Nathan Bossart,
>> 2025-01-10), which first shipped in PostgreSQL 18, to the supported
>> back branches: REL_17_STABLE, REL_16_STABLE and REL_15_STABLE.
>
> I think that's fine. It was likely an oversight when AArch64 support was
> first added to this file, anyway. We could also back-patch to v14, but
> that would look a little different since it is missing commit a82a5eee31
> ("Use ISB as a spin-delay instruction on ARM64"). Since v14 is set to go
> out-of-support in a couple months, I'd probably just stop at v15 and call
> it a day, though.
+1 for backpatching to v15
> With huge_pages=on both effects largely disappear: huge pages mask the
>> paging defect, and TTAS is neutral.
>>
>> The change is a one-line, so a backport looks low-risk and would spare
>> pre-18 AArch64 users a severe regression as PREEMPT_LAZY kernels ship.
>
> I'm curious why you are testing without huge pages enabled. My
> understanding is that any serious workload on the kinds of machines you are
> using for your benchmarks would use them.
I agree with Nathan, that should have a positive impact. 95GiB shared_buffers
on 4 KB pages is a TLB disaster. With ~4 KB pages, a buffer pool that size
needs ~25 million page-table entries; the TLB on Graviton4 cores covers only
a few thousand entries, so heavy concurrent access to shared memory causes
constant TLB misses and page-table walks. I bet you can measure for this
effect to validate that's happening.
2 MB (or larger) pages cut the translation footprint by ~500x, give it a
try.
best.
-greg
> --
> nathan
