On Tue, Dec 7, 2010 at 12:50 PM, Tom Lane <tgl@xxxxxxxxxxxxx> wrote: > Robert Haas <robertmhaas@xxxxxxxxx> writes: >> I wonder if it would be possible to have a very short critical section >> where we grab the partition lock, acquire the heavyweight lock, and >> release the partition lock; and then only as a second step record (in >> the form of a PROCLOCK) the fact that we got it. > > [ confused... ] Exactly what do you suppose "acquire the lock" would > be represented as, if not "create a PROCLOCK entry attached to it"? Update the "granted" array and, if necessary, the grantMask. > In any case, I think this is another example of not understanding where > the costs really are. Possible. > As far as I can tell, on modern MP systems much > of the elapsed time in these operations comes from acquiring exclusive > access to shared-memory cache lines. Reducing the number of changes you > have to make within a small area of shared memory won't save much, once > you've paid for the first one. Seems reasonable. > Changing structures that aren't heavily > contended (such as a proc's list of its own locks) doesn't cost much at > all. I'm not sure where you're getting the idea that a proc's list of its own locks isn't heavily contended. That could be true, but it isn't obvious to me. We allocate PROCLOCK structures out of a shared hash table while holding the lock manager partition lock, and we add every lock to a queue associated with the PROC and a second queue associated with the LOCK. So if two processes acquire an AccessShareLock on the same table, both the LOCK object and at least the SHM_QUEUE portions of each PROCLOCK are shared, and those aren't necessarily nearby in memory. > One thing that might be interesting, but that I don't know how to attack > in a reasonably machine-independent way, is to try to ensure that shared > and local data structures don't accidentally overlap within cache lines. > When they do, you pay for fighting the cache line away from another > processor even when there's no real need. I'd be sort of surprised if this is a problem - as I understand it, cache lines are small, contiguous chunks, and surely the heap and the shared memory segment are mapped into different portions of the address space... -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
