On Mon, Jan 2, 2017 at 4:04 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> But that doesn't really detract from my point, which is that it's
>> totally silly for us to imagine that char and word-wide atomic ops are
>> interchangeable on all platforms and we can flip a coin to decide which
>> to use as long as the configure probes don't fail outright. Even given
>> working code for the byte case, we ought to prefer int atomics on PPC.
>> On other platforms, maybe the preference goes the other way. I'd be
>> inclined to follow the hard-won knowledge embedded in s_lock.h about
>> which to prefer.
>
> After further study, I'm inclined to just propose that we flip the default
> width of pg_atomic_flag in generic-gcc.h: use int not char if both are
> available. The only modern platform where that's the wrong thing is x86,
> and that case is irrelevant here because we'll be using arch-x86.h not
> generic-gcc.h.
>
> A survey of s_lock.h shows that we prefer char-width slock_t only on
> these architectures:
>
> x86
> sparc (but not sparcv9, there we use int)
> m68k
> vax
I don't think that's right, because on my MacBook Pro:
(gdb) p sizeof(slock_t)
$1 = 1
(gdb)
On Linux x86_64:
(gdb) p sizeof(slock_t)
$1 = 1
I think we would be well-advised to get the size of slock_t down to a
single byte on as many platforms as possible, because when it's any
wider than that it makes some critical structures that would otherwise
fit into a cache line start to not fit, and that can have a very big
impact on performance. I'm disappointed to notice that it's 4 bytes
wide on hydra (ppc64).
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company