On Mon, Jan 2, 2017 at 4:04 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
