Re: spinlocks on powerpc

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Jeremy Harris <jgh(at)wizmail(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: spinlocks on powerpc
Date: 2012-01-03 20:48:58
Message-ID: 25841.1325623738@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Jan 3, 2012 at 3:05 PM, Jeremy Harris <jgh(at)wizmail(dot)org> wrote:
>> Also, heavy-contention locks should be placed in cache lines away from other
>> data (to avoid thrashing the data cache lines when processors are fighting
>> over the lock cache lines).

> Yep. This is possibly a problem, and has been discussed before, but I
> don't think we have any firm evidence that it's a problem, or how much
> padding helps. The heavily contended LWLocks are mostly
> non-consecutive, except perhaps for the buffer mapping locks.

We are in fact already padding and aligning LWLocks on (if memory
serves) 16 or 32 byte boundaries depending on platform. So there
might be 2 to 4 LWLocks in the same cache line, depending on platform.
It's been suggested before that we pad more to reduce this number,
but nobody's demonstrated any performance win from doing so.

> It's been suggested to me that we should replace our existing LWLock
> implementation with a CAS-based implementation that crams all the
> relevant details into a single 8-byte word.

I'm under the impression that the main costs are associated with trading
cache line ownership between CPUs, which makes me think that this'd be
essentially a waste of effort, quite aside from the portability problems
involved.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2012-01-03 20:55:02 Re: ALTER TABLE lock strength reduction patch is unsafe
Previous Message Alexander Korotkov 2012-01-03 20:48:54 Re: Collect frequency statistics for arrays