Re: Spinlocks and CPU Architectures

Simon Riggs <simon(at)2ndquadrant(dot)com> writes:
> The long history of spinlock issues has recently been attacked
> significantly by Tom, but I wanted to get a status on this issue before
> we release 8.1

I'd still like to do something more with that before we release, but
exactly what is TBD.

> The conclusion I draw from all of this is that the spinlock code needs
> to be specialised for individual hardware architectures, not just
> instruction sets. That is, we need different code for Intel and AMD, as
> well as for other CPU types - *if* you want it to perform well for SMP.

This seems pretty unworkable from a packaging standpoint. Even if you
teach autoconf how to tell which model it's running on, there's no
guarantee that the resulting executables will be used on that same
machine. We would have to make a run-time test, and I do not think that
that idea is attractive either --- adding a conditional branch to the
spinlock code will likely negate whatever performance improvement we
could hope to get.

As far as the x86_64 TAS code is concerned, my inclination is to remove
the cmpb test; that's a significant win on Opteron and only a small loss
on EM64T. There is not evidence to justify removing cmpb on x86
architecture, but we can easily split the x86 and x86_64 cases.

I'd also like to apply some form of the adaptive-spin-delay patch that
was discussed last month.

regards, tom lane