Re: Proposal: Removing 32 bit support starting from PG17++

Hi,

On 2023-05-24 17:44:36 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > Dropping CPUs without native atomic operations / without a way to do tear-free
> > 8 byte reads would make several substantial performance improvements easier,
> > while not really dropping any relevant platform.
>
> Hmm, can we really expect atomic 8-byte reads on "relevant" 32-bit
> platforms?  I'd be on board with this if so, but it sounds a bit
> optimistic.

Combining https://wiki.postgresql.org/wiki/Atomics with our docs:

>  In general, PostgreSQL can be expected to work on these CPU architectures:
>  x86, PowerPC, S/390, SPARC, ARM, MIPS, RISC-V, and PA-RISC, including
>  big-endian, little-endian, 32-bit, and 64-bit variants where applicable. It
>  is often possible to build on an unsupported CPU type by configuring with
>  --disable-spinlocks, but performance will be poor.


On x86 8 byte atomics are supported since the 586 - released in 1993. I don't
think we need to care about i386 / i486?

PPC always had it from what I can tell (the docs don't mention a minimum
version).

Sparc has supported single copy atomicity for 8 byte values since sparc v9, so
~1995 (according to wikipedia there was one V8 chip released in 1996, there's
also "LEON", a bit later, but that's "V8E", which includes the atomicity
guarantees from v9).

On s390 sufficient instructions to make 64bit atomics work natively are
supported (just using cmpxchg).

On older arm it's supported via kernel emulation - which afaict is better than
falling back to a semaphore, our current fallback. I don't currently have
access to armv7*, so I can't run a benchmark.


So the only problematic platforms are 32 bit MIPS and PA-RISC.


I'm not entirely sure whether my determination about 32 bit MIPS from back
then is actually true - I might have read the docs too narrowly back then or
they were updated since. In a newer version of the manual I see:

> The paired instructions, Load Linked and Store Conditional, can be used to
> perform an atomic read-modify-write of word or doubleword cached memory
> locations.

The word width is referenced to be 32bit earlier on the same page. And it's
documented to be true for mips32, not just mips64.

With that one can implement a 64bit cmpxchg, and with 64bit cmpxchg one can
implement a, not too efficient, tear-free read.


What gave me pause for a moment is that both clang and gcc generate calls to
external functions on 32 bit mips - but they do provide libatomic and looking
at the disassembly, there does appear to be a some non-emulated execution. But
tbh, there are so many ABIs and options that I am not sure what is what.

Reading the https://en.wikipedia.org/wiki/MIPS_architecture history part gives
me a headache: "During the mid-1990s, many new 32-bit MIPS processors for
embedded systems were MIPS II implementations because the introduction of the
64-bit MIPS III architecture in 1991 left MIPS II as the newest 32-bit MIPS
architecture until MIPS32 was introduced in 1999.[3]: 19 "

My rough understanding is that it's always doable in 64 mode, and has been
available in 32bit mode for a long time, but that it depends on the the ABI
used.


So it looks like the only certain problem is PA-RISC - which I personally
wouldn't include in "relevant" :), with some evaluation needed for 32bit mips
and old arms.


Greetings,

Andres Freund