Merlin Moncure <mmoncure@gmail.com> writes:
> I think there is some very low hanging optimization fruit in the clock
> sweep loop. first and foremost, I see no good reason why when
> scanning pages we have to spin and wait on a buffer in order to
> pedantically adjust usage_count. some simple refactoring there could
> set it up so that a simple TAS (or even a TTAS with the first test in
> front of the cache line lock as we done automatically in x86 IIRC)
> could guard the buffer and, in the event of any lock detected, simply
> move on to the next candidate without messing around with that buffer
> at all. This could construed as a 'trylock' variant of a spinlock
> and might help out with cases where an especially hot buffer is
> locking up the sweep. This is exploiting the fact that from
> StrategyGetBuffer we don't need a *particular* buffer, just *a*
> buffer.
Hm. You could argue in fact that if there's contention for the buffer
header, that's proof that it's busy and shouldn't have its usage count
decremented. So this seems okay from a logical standpoint.
However, I'm not real sure that it's possible to do a conditional
spinlock acquire that doesn't create just as much hardware-level
contention as a full acquire (ie, TAS is about as bad whether it
gets the lock or not). So the actual benefit is a bit less clear.
regards, tom lane
