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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
