Skip site navigation (1) Skip section navigation (2)

LWLock cache line alignment

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "pgsql-hackers" <pgsql-hackers(at)postgresql(dot)org>
Subject: LWLock cache line alignment
Date: 2005-02-03 06:10:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Following some advice from Intel,
I'm looking at whether the LWLock data structures may be within the same
cache line.

Intel uses 128 byte cache lines on its high end processors.

slru.c uses BUFFERALIGN which is currently hardcoded in
pg_config_manual.c to be
which seems to be the wrong setting for the Intel CPUs, possibly others.

In slru.c we have this code fragment:
/* Release shared lock, grab per-buffer lock instead */
		LWLockAcquire(shared->buffer_locks[slotno], LW_EXCLUSIVE);

The purpose of this is to reduce contention, by holding finer grained
locks. ISTM what this does is drop one lock then take another lock by
accessing an array (buffer_locks) which will be in the same cache line
for all locks, then access the LWLock data structure, which again will
be all within the same cache line. ISTM that we have fine grained
LWLocks, but not fine grained cache lines. That means that all Clog and
Subtrans locks would be effected, since we have 8 of each.

For other global LWlocks, the same thing applies, so BufMgrLock and many
other locks are effectively all the same from the cache's perspective.

...and BTW, what is MMCacheLock?? is that an attempt at padding already?

It looks like padding out LWLock struct would ensure that each of those
were in separate cache lines?

Any views?

Best Regards, Simon Riggs


pgsql-hackers by date

Next:From: Tom LaneDate: 2005-02-03 06:32:03
Subject: Re: Crash when inserting gist records, or creating index on ( int, geom )
Previous:From: Tom LaneDate: 2005-02-03 05:17:19
Subject: Re: subselects in the target list

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group