Re: spinlocks on HP-UX

On Mon, Aug 29, 2011 at 11:07 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> OK, done.  I think while we're tidying up here we ought to do
>> something about this comment:
>
>>  *      ANOTHER CAUTION: be sure that TAS(), TAS_SPIN(), and
>> S_UNLOCK() represent
>>  *      sequence points, ie, loads and stores of other values must not be moved
>>  *      across a lock or unlock.  In most cases it suffices to make
>> the operation
>>  *      be done through a "volatile" pointer.
>
>> IIUC, this is basically total nonsense.
>
> It could maybe be rewritten for more clarity, but it's far from being
> nonsense.  The responsibility for having an actual hardware memory fence
> instruction lies with the author of the TAS macro.

Right... but the comment implies that you probably don't need one, and
doesn't even mention that you MIGHT need one.

>> In the department of loose ends, there are a bunch of other things
>> that maybe need cleanup here: (1) the gcc/intel compiler cases on
>> ia64, (2) PA-RISC, (3) ARM, (4) PowerPC... and we should also perhaps
>> reconsider the 32-bit x86 case.
>
> The results I got yesterday seem sufficient basis to change the
> gcc/intel cases for IA64, so I will go do that if you didn't already.

I did not; please go ahead. I wasn't relishing the idea trying to
figure out how to install gcc to test that case.

> I am also currently running tests on x86_64 and PPC using Red Hat test
> machines --- expect results later today.  Red Hat doesn't seem to own
> any many-CPU machines that are 32-bit-only, and I rather wonder if there
> are any.  It might be that it only makes sense to optimize the x86 paths
> for a few CPUs, in which case this test methodology may not be very
> helpful.

FWIW, I tried spinning unlocked on x86_64 at 32 cores and got a
regression. Don't have any PPC gear at present.

I think optimizing spinlocks for machines with only a few CPUs is
probably pointless. Based on what I've seen so far, spinlock
contention even at 16 CPUs is negligible pretty much no matter what
you do. Whether your implementation is fast or slow isn't going to
matter, because even an inefficient implementation will account for
only a negligible percentage of the total CPU time - much less than 1%
- as opposed to a 64-core machine, where it's not that hard to find
cases where spin-waits consume the *majority* of available CPU time
(recall previous discussion of lseek). So I'm disinclined to spend
the time it would take to tinker with the 32-bit code, because it will
not matter; for that platform we're better off spending our time
installing a hash table in ScanKeywordLookup(). And there's always a
possibility that AMD and Intel chips could be different, or there
could even be differences between different chip generations from the
same manufacturer, so all in all it seems like a pretty unrewarding
exercise.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company