* Robert Haas (robertmhaas@gmail.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
