On Sun, Jun 12, 2011 at 5:58 PM, Greg Stark <stark@mit.edu> wrote:
> On Sun, Jun 12, 2011 at 10:39 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> I hacked up the system to
>> report how often each lwlock spinlock exceeded spins_per_delay.
>
> I don't doubt the rest of your analysis but one thing to note, number
> of spins on a spinlock is not the same as the amount of time spent
> waiting for it.
>
> When there's contention on a spinlock the actual test-and-set
> instruction ends up taking a long time while cache lines are copied
> around. In theory you could have processes spending an inordinate
> amount of time waiting on a spinlock even though they never actually
> hit spins_per_delay or you could have processes that quickly exceed
> spins_per_delay.
>
> I think in practice the results are the same because the code the
> spinlocks protect is always short so it's hard to get the second case
> on a multi-core box without actually having contention anyways.
All good points. I don't immediately have a better way of measuring
what's going on. Maybe dtrace could do it, but I don't really know
how to use it and am not sure it's set up on any of the boxes I have
for testing. Throwing gettimeofday() calls into SpinLockAcquire()
seems likely to change the overall system behavior enough to make the
results utterly meaningless. It wouldn't be real difficult to count
the number of times that we TAS() rather than just counting the number
of times we TAS() more than spins-per-delay, but I'm not sure whether
that would really address your concern. Hopefully, further
experimentation will make things more clear.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
