Robert Haas <robertmh...@gmail.com> writes:
> On Tue, Jan 3, 2012 at 3:05 PM, Jeremy Harris <j...@wizmail.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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
