Re: [PATCH] Reduce LWLockWaitListLock() cache-line contention with adaptive spin reads

From: "Okanovic, Haris" <harisokn(at)amazon(dot)com>
To: wenhui qiu <qiuwenhuifx(at)gmail(dot)com>, "Min, Baohong" <baohong(dot)min(at)intel(dot)com>
Cc: "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Reduce LWLockWaitListLock() cache-line contention with adaptive spin reads
Date: 2026-09-18 21:11:30
Message-ID: MN7PR18MB660231D56BF8FD8839F98F539DA8872@MN7PR18MB660231.namprd18.prod.outlook.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Wenhui, Baohong,

> Please consider adding benchmark results from at least one non-Intel
> platform.

I benchmarked your v1 on AWS Graviton (Arm Neoverse N1/V1/V2/V3) on top
of postgres master f7cc6fd760: ran pgbench with 3 different workloads
over various machine sizes and client counts. I measured up to 59%
higher peak throughput on 192-core V3, up to 14% on 192-core V2, and no
change or regressions on small systems.

Result details can be found in these plots:
https://github.com/harisokanovic/harismisc/tree/master/postgres/pgsqlscaling/adaptiveSpinReads-bench-2026-09-18/

For context, I have also been trying to improve LWLockWaitListLock()
using futex-mutex, but so far this approach doesn't benchmark well on
x86_64 systems, and was conditioned on aarch64-only.

The futex-mutex variant:
https://www.postgresql.org/message-id/DM6PR18MB29081469262A7BBCE85220B3A8112%40DM6PR18MB2908.namprd18.prod.outlook.com

Regards,
Haris Okanovic
AWS Graviton

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Sami Imseih 2026-09-18 21:19:20 Add REPACK progress phases for logical decoding setup
Previous Message Jacob Champion 2026-09-18 21:04:49 [PATCH] Add a check_hook for output_plugin_libraries