Re: Reasoning behind LWLOCK_PADDED_SIZE/increase it to a full cacheline

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Reasoning behind LWLOCK_PADDED_SIZE/increase it to a full cacheline
Date: 2013-09-24 10:39:39
Message-ID: 5840.1380019179@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> So, what we do is we guarantee that LWLocks are aligned to 16 or 32byte
> boundaries. That means that on x86-64 (64byte cachelines, 24bytes
> unpadded lwlock) two lwlocks share a cacheline.

Yup.

> In my benchmarks changing the padding to 64byte increases performance in
> workloads with contended lwlocks considerably.

At a huge cost in RAM. Remember we make two LWLocks per shared buffer.

I think that rather than using a blunt instrument like that, we ought to
see if we can identify pairs of hot LWLocks and make sure they're not
adjacent.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-09-24 10:48:11 Re: Reasoning behind LWLOCK_PADDED_SIZE/increase it to a full cacheline
Previous Message Bernd Helmle 2013-09-24 09:58:25 Re: ENABLE/DISABLE CONSTRAINT NAME