Re: Performance under contention

On Tue, Dec 7, 2010 at 12:50 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> 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