Hi,
I am a software engineer with Google's AlloyDB. We recently implemented more granular spinlock wait event tracking and I wanted to propose it here. I can create a patch if the community here deems it suitable for incorporating into postgres. Here is the overall idea:
We categorise the spinlocks based on the location (filename and line number) where they are initialized (via SpinLockInit).
We change slock_t to a struct that contains the actual lock variable and an id (we just need a byte for it). We also allocate a shared memory array (128 entries by 128 bytes) for storing the filename:line_number identifiers. During SpinLockInit, we use the filename:line_number combo of the caller and do a lookup for it in the array, adding an entry if the combination is not found. The index of the entry is the identifier that will be stored in the lock struct. This identifier is then set in the SpinDelayStatus which is then used to set the new wait event id when reporting SpinDelay (we add a new wait event class for SpinLock). The name of the wait event is of the form 'SpinLock_filename:linenum'.
Pros of this approach: The changes are pretty much limited to the spinlock related files and the APIs for SpinLock initialization, acquisition and release do not change. There is also no additional overhead during spinlock acuire and release.
Cons of this approach: Overhead of storing the id with each lock and extra work during SpinLockInit.
We adopted this approach internally since we did not notice performance regressions in our tests. However, the platforms we run on with AlloyDB are only a subset of what postgres supports, so I am open to doing additional testing on my patch if there are suggestions (right now it passes 'make check' on my local build).
I would appreciate any feedback and suggestions on this.
Zaeem
