Re: Optimize LWLock scalability via ReadBiasedLWLock for heavily-shared locks

Hi,

On 2025-06-26 13:07:49 +0800, Zhou, Zhiguo wrote:
> This patch addresses severe LWLock contention observed on high-core systems
> where hundreds of processors concurrently access frequently-shared locks.
> Specifically for ProcArrayLock (exhibiting 93.5% shared-mode acquires), we
> implement a new ReadBiasedLWLock mechanism to eliminate the atomic operation
> bottleneck.
> 
> Key aspects:
> 1. Problem: Previous optimizations[1] left LWLockAttemptLock/Release
> consuming
>    ~25% total CPU cycles on 384-vCPU systems due to contention on a single
>    lock-state cache line. Shared lock attempts showed 37x higher cumulative
>    latency than exclusive mode for ProcArrayLock.
> 
> 2. Solution: ReadBiasedLWLock partitions lock state across 16 cache lines
>    (READ_BIASED_LOCK_STATE_COUNT):
>    - Readers acquire/release only their designated LWLock (indexed by
>      pid % 16) using a single atomic operation
>    - Writers pay higher cost by acquiring all 16 sub-locks exclusively
>    - Maintains LWLock's "acquiring process must release" semantics
> 
> 3. Performance: HammerDB/TPCC shows 35.3% NOPM improvement over baseline
>    - Lock acquisition CPU cycles reduced from 16.7% to 7.4%
>    - Lock release cycles reduced from 7.9% to 2.2%
> 
> 4. Implementation:
>    - Core infrastructure for ReadBiasedLWLock
>    - ProcArrayLock converted as proof-of-concept
>    - Maintains full LWLock API compatibility
> 
> Known considerations:
> - Increased writer acquisition cost (acceptable given rarity of exclusive
>   acquisitions for biased locks like ProcArrayLock)

Unfortunately I have a very hard time believing that that's unacceptable -
there are plenty workloads (many write intensive ones) where exclusive locks
on ProcArrayLock are the bottleneck.

Greetings,

Andres Freund