I wrote:
> it might be that the only machines that actually spit up on the hint bit
> (rather than ignore it) were 32-bit, in which case this would be a
> usable heuristic. Not sure how we can research that ... do we want to
> just assume the kernel guys know what they're doing?
I did a bit of research on this. The EH hint bit for LWARX was
introduced in Power ISA 2.05 of 2007,
https://www.power.org/resources/reading/PowerISA_V2.05.pdf
which states:
Warning: On some processors that comply with versions of the
architecture that precede Version 2.00, executing a Load And Reserve
instruction in which EH = 1 will cause the illegal instruction error
handler to be invoked.
According to wikipedia and some other sites, 2.00 corresponds to POWER4
(introduced in 2001), which was *not* the first 64-bit POWER
architecture; before that there was POWER3 (used in IBM RS/6000 for a
couple of years) and PPC 620 (not commercially successful, in particular
never used by Apple). However I could not find anything definitive as
to whether those particular chips would give SIGILL for the hint bit
being set. So there may or may not be a small population of old 64-bit
PPC chips on which the hint bit would cause trouble. Certainly it
should be safe on the vast majority of currently operational PPC64
machines.
In the other direction, it's at least possible that someone would want
to build PG as 32-bit on a PPC machine that is new enough to support the
hint bit.
What I suggest we should do about this is provide an overridable option
in pg_config_manual.h, along the lines of
#if defined(__ppc64__) || defined(__powerpc64__)#define USE_PPC_LWARX_MUTEX_HINT#endif
and then test that symbol in s_lock.h. This will provide an escape
hatch for anyone who doesn't want the decision tied to 64-bit-ness,
while still enabling the option automatically for the majority of
people who could use it.
BTW, while reading the ISA document I couldn't help noticing that LWARX
is clearly specified to operate on 4-byte quantities (there's LDARX if
you want to use 8-byte). Which seems to mean that this bit in s_lock.h
just represents bogus waste of space:
#if defined(__ppc64__) || defined(__powerpc64__)
typedef unsigned long slock_t;
#else
typedef unsigned int slock_t;
#endif
Shouldn't we just make slock_t be "int" for both PPC and PPC64?
regards, tom lane
