From: Salvatore Dipietro <dipiets@amazon.it>
To: <nathandbossart@gmail.com>, <greg@burd.me>
CC: <pgsql-hackers@lists.postgresql.org>, <mrdrivingduck@gmail.com>,
	<andres@anarazel.de>, <tgl@sss.pgh.pa.us>, <dipietro.salvatore@gmail.com>
Subject: Re: use a non-locking initial test in TAS_SPIN on AArch64
Date: Wed, 16 Sep 2026 12:08:48 +0000
Message-ID: <20260916120848.3437130-1-dipiets@amazon.it>
In-Reply-To: <6EDE0F59-5517-4F52-9584-A9252E59317E@burd.me>
References: <6EDE0F59-5517-4F52-9584-A9252E59317E@burd.me>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20260916120848.3437130-1-dipiets%40amazon.it>
Precedence: bulk


>> On Sep 15, 2026, at 10:51 AM, Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>> 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.
>
> On Sep 15, 2026, at 13:51 AM, Burd, Greg <greg(at)burd(dot)me> wrote:
> 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.

We routinely test both huge_pages=on and huge_pages=off. The hp=off case
matters because huge_pages defaults to "try" and Linux does not
preallocate a hugepage pool, so unless the operator sets it manually the
server falls back to 4K pages. The regression is also more evident on
this instance because of the high core count and the contention that
comes with it; I would expect it on smaller instances too with a more
limited impact, though I have not measured that.

As expected, with hugepage=off the system is more under stress and TTAS
shows a bigger improvement, but we tested hugepage=on as well (2 MB
pages, preallocated pool of 54,612 pages for the 95 GB shared_buffers):

  | PG          | 6.1     | v7.2    | v7.2+fix |
  |-------------|--------:|--------:|---------:|
  | 17.10 stock | 144,162 | 176,377 |  156,885 |
  | 17.10 TTAS  | 148,997 | 185,961 |  185,524 |
  | 17.10 gain  |   +3.4% |   +5.4% |   +18.3% |

Even with PG 17 and hugepages, TTAS still delivers some gains with
kernel v7.2, though the gain is much smaller than with hugepage=off.

For PG 15 and 16 with huge_pages=on, stock and TTAS come out close,
83-92k either way, so the limiter there is elsewhere.

Salvatore


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