Re: use a non-locking initial test in TAS_SPIN on AArch64

From: Salvatore Dipietro <dipiets(at)amazon(dot)it>
To: <nathandbossart(at)gmail(dot)com>
Cc: <pgsql-hackers(at)lists(dot)postgresql(dot)org>, <mrdrivingduck(at)gmail(dot)com>, <andres(at)anarazel(dot)de>, <tgl(at)sss(dot)pgh(dot)pa(dot)us>, <dipietro(dot)salvatore(at)gmail(dot)com>
Subject: Re: use a non-locking initial test in TAS_SPIN on AArch64
Date: 2026-09-15 11:46:23
Message-ID: 20260915114623.431827-1-dipiets@amazon.it
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


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.

The trigger is a kernel change, not a PostgreSQL one: Linux made
PREEMPT_LAZY the default in v7.0. A backend can now be preempted while
holding a spinlock, causing a drop in performance.

Setup: AWS Graviton4 (m8g.24xlarge, 96 vCPU, 384 GB), Amazon Linux
2023, pgbench built-in simple-update, scale 8470, prepared protocol,
1024 clients, 1200 s per run, shared_buffers 95 GB. PostgreSQL 15.18,
16.14, 17.10, 18.4. Two kernels: AL2023 stock 6.1.182-227.379 (no
PREEMPT_LAZY) and linux-next 7.2.0-8d3ae5928 (PREEMPT_LAZY by default).

Kernel v6.5+ also carries a second, unrelated regression in the folio
allocation for which we have proposed a kernel fix separately [1]. Both
defects cap TPS at roughly the same level, so the paging one hides most
of the spinlock effect. Look at the "v7.2+fix" columns to see the
spinlock on its own.

TPS with huge_pages=off, and the TTAS-vs-stock gain per kernel:

| PG | 6.1 | v7.2 | v7.2+fix |
|-------------|--------:|-------:|---------:|
| 15.18 stock | 75,799 | 41,155 | 43,636 |
| 15.18 TTAS | 80,858 | 56,198 | 82,212 |
| 15.18 gain | +6.7% | +36.6% | +88% |
| 16.14 stock | 75,667 | 39,952 | 39,592 |
| 16.14 TTAS | 80,746 | 57,604 | 77,747 |
| 16.14 gain | +6.7% | +44.2% | +96% |
| 17.10 stock | 137,630 | 69,751 | 69,003 |
| 17.10 TTAS | 150,794 | 81,487 | 157,436 |
| 17.10 gain | +9.6% | +16.8% | +128% |
| 18.4 native | 148,467 | 79,820 | 143,473 |

So on a PREEMPT_LAZY kernel with the paging defect fixed, the one-line
change is worth +88% to +128% on PG 15-17. PG 17.10 with the backport
also tracks PG 18.4's native behaviour closely on both kernels.

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.

Thanks,
Salvatore

[1] https://lore.kernel.org/linux-mm/20260911142102(dot)2294202-1-dipiets(at)amazon(dot)it/T/#u

AMAZON DEVELOPMENT CENTER ITALY SRL, viale Monte Grappa 3/5, 20124 Milano, Italia, Registro delle Imprese di Milano Monza Brianza Lodi REA n. 2504859, Capitale Sociale: 10.000 EUR i.v., Cod. Fisc. e P.IVA 10100050961, Societa con Socio Unico

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2026-09-15 11:59:10 Re: Trying to break online checksums with LLMs
Previous Message solai v 2026-09-15 11:33:57 Re: [PATCH] Add row estimate tests for unnest() and integer generate_series()