Re: dynamic shared memory and locks

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> Another idea is to include some identifying information in the lwlock.

That was my immediate reaction to this issue...

> For example, each lwlock could have a char *name in it, and we could
> print the name. In theory, this could be a big step forward in terms
> of usability, because it'd spare us all needing to remember that 4 ==
> ProcArrayLock. But it's awkward for buffer locks, of which there
> might be a great many, and we surely don't want to allocate a
> dynamically-generated string in shared memory for each one. You could
> do a bit better by making the identifying information a string plus an
> integer, because then all the buffer locks could set the string to a
> static constant like "buffer content lock" and the integer to the
> buffer number, and similarly for lock manager partition locks and so
> on. This is appealing, but would increase the size of LWLockPadded
> from 16 bytes to 32 on 64-bit platforms where slock_t is four bytes or
> less, which I'm not that excited about even though it would reduce
> cache line contention in some cases.

I'm not thrilled with this either but at the same time, it may well be
worth it.

> Yet a third idea is to try to reverse-engineer a name for a given
> lwlock from the pointer address. If it's an offset into the main
> array, this is easy enough to do, and even if we ended up with several
> arrays (like one for bufmgr locks) it wouldn't be too hard to write
> code to figure out which array contains it and emit the appropriate
> string. The only real problem that I see with this is that it might
> cause a performance hit. A performance hit when running with
> trace_lwlocks or LWLOCK_STATS is not really a problem, but people
> won't like if --enable-dtrace slow things up.

This seems like an interesting idea- but this and my other thought
(having a defined array of strings) seem like they might fall over in
the face of DSMs.

> Preferences, other ideas?

My preference would generally be "use more memory rather than CPU time";
so I'd vote for adding identifying info rather than having the code hunt
through arrays to try and find it.

> None of these ideas are a complete solution for LWLOCK_STATS. In the
> other three cases noted above, we only need an identifier for the lock
> "instantaneously", so that we can pass it off to the logger or dtrace
> or whatever. But LWLOCK_STATS wants to hold on to data about the
> locks that were visited until the end of the session, and it does that
> using an array that is *indexed* by lwlockid. I guess we could
> replace that with a hash table. Ugh. Any suggestions?

Yeah, that's not fun. No good suggestions here offhand.

Thanks,

Stephen