Обсуждение: Proposal: Removing 32 bit support starting from PG17++

Hans Buschmann <buschmann@nidsa.net> writes:
> This inspired me to propose dropping 32bit support for PostgreSQL starting with PG17.

I don't think this is a great idea.  Even if Intel isn't interested,
there'll be plenty of 32-bit left in the lower end of the market
(think ARM, IoT, and so on).

            regards, tom lane

Hi,

On 2023-05-24 14:33:06 +0000, Hans Buschmann wrote:
> I recently stumbled over the following Intel proposal for dropping 32bit support in x86 processors. [1]

It's a proposal for something in the future. Which, even if implemented as is,
will affect future hardware, several years down the line. I don't think that's
a good reason for removing 32 bit support in postgres.

And postgres is used on non-x86 architectures...


> This inspired me to propose dropping 32bit support for PostgreSQL starting
> with PG17.
> ...
> Even if I am not a postgres hacker I suppose this could simplify things quite a lot.

There's some simplification, but I don't think it'd be that much.

I do think there are code removals and simplifications that would be bigger
than dropping 32bit support.

Dropping support for effectively-obsolete compilers like sun studio (requires
random environment variables to be exported to not run out of memory) and
AIX's xlc (requires a lot of extra compiler flags to be passed in for a sane
build) would remove a fair bit of code.

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.

Etc.

Greetings,

Andres Freund

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.

            regards, tom lane

On Wed, May 24, 2023 at 10:44:11AM -0400, Tom Lane wrote:
> Hans Buschmann <buschmann@nidsa.net> writes:
> > This inspired me to propose dropping 32bit support for PostgreSQL starting with PG17.
>
> I don't think this is a great idea.  Even if Intel isn't interested,
> there'll be plenty of 32-bit left in the lower end of the market
> (think ARM, IoT, and so on).

A few examples of that are the first models of the Raspberry PIs,
which are still produced (until 2026 actually for the first model).
These rely on ARMv6 if I recall correctly, which are 32b.
--
Michael

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

Andres Freund <andres@anarazel.de> writes:
> On 2023-05-24 17:44:36 -0400, Tom Lane wrote:
>> 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.

> ...

> 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.

You'll no doubt be glad to hear that I'll be retiring chickadee
in the very near future.  (I'm moving/downsizing, and that machine
isn't making the cut.)  So dropping PA-RISC altogether should probably
happen for v17, maybe even v16.  Seems like we should poke into
ARM more closely, though.

            regards, tom lane

On Thu, May 25, 2023 at 11:51 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2023-05-24 17:44:36 -0400, Tom Lane wrote:
> > 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.
>
> You'll no doubt be glad to hear that I'll be retiring chickadee
> in the very near future.

. o O { I guess chickadee might have been OK anyway, along with e.g.
antique low-end SGI MIPS gear etc of "workstation"/"desktop" form that
any collector is likely to have still running, because they only had
one CPU (unlike their Vogon-spaceship-sized siblings).  As long as
they had 64 bit load/store instructions, those couldn't be 'divided'
by an interrupt, so scheduler switches shouldn't be able to tear them,
AFAIK? }

Thomas Munro <thomas.munro@gmail.com> writes:
> On Thu, May 25, 2023 at 11:51 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> You'll no doubt be glad to hear that I'll be retiring chickadee
>> in the very near future.

> . o O { I guess chickadee might have been OK anyway, along with e.g.
> antique low-end SGI MIPS gear etc of "workstation"/"desktop" form that
> any collector is likely to have still running, because they only had
> one CPU (unlike their Vogon-spaceship-sized siblings).  As long as
> they had 64 bit load/store instructions, those couldn't be 'divided'
> by an interrupt, so scheduler switches shouldn't be able to tear them,
> AFAIK? }

PA-RISC can probably do tear-free 8-byte reads, but Andres also
wanted to raise the bar enough to include 32-bit atomic instructions,
which PA-RISC hasn't got; the one such instruction it has is
limited enough that you can't do much beyond building a spinlock.

Dunno about antique MIPS.  I think there's still some interest in
not-antique 32-bit MIPS; I have some current-production routers
with such CPUs.  (Sadly, they don't have enough storage to do
anything useful with, or I'd think about repurposing one for
buildfarm.)

            regards, tom lane

Hi,

On 2023-05-24 19:51:22 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > On 2023-05-24 17:44:36 -0400, Tom Lane wrote:
> >> 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.
> 
> > ...
> 
> > 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.
> 
> You'll no doubt be glad to hear that I'll be retiring chickadee
> in the very near future.

Heh, I have to admit, I am.


> So dropping PA-RISC altogether should probably happen for v17, maybe even
> v16.

Definitely for 17 - not sure if we have much to gain by doing it in 16. The
likelihood that somebody will find a PA-RISC specific bug, after we dropped
support for 15, is pretty low, I think.


> Seems like we should poke into ARM more closely, though.

Looks like the necessary support was added in armv6k and armv7a:

https://developer.arm.com/documentation/dui0489/i/arm-and-thumb-instructions/strex
  ARM STREXB, STREXD, and STREXH are available in ARMv6K and above.
  All these 32-bit Thumb instructions are available in ARMv6T2 and above, except that STREXD is not available in the
ARMv7-Marchitecture.
 

ARMv7-M is for microcontrollers without an MMU, so it's not going to be used
for postgres.

The arm buildfarm machines (using the architecture names from there) we have
are:

armv6l: chipmunk
ARMv7: mereswine, gull, grison
arm64: dikkop, sifaka, indri

turako says it's armv7l, but it seems actually to target aarch64.

At least for type of machine available on the buildfarm, it looks like we
actually should be good. They all appear to already be supporting 64bit
atomics, without needing further compiler flags.

Greetings,

Andres Freund

Andres Freund <andres@anarazel.de> writes:
> On 2023-05-24 19:51:22 -0400, Tom Lane wrote:
>> So dropping PA-RISC altogether should probably happen for v17, maybe even
>> v16.

> Definitely for 17 - not sure if we have much to gain by doing it in 16.

I'm just thinking that we'll have no way to test it.  I wouldn't advocate
such a change in released branches; but I think it'd be within policy
still for v16, and that would give us one less year of claimed support
for an arch we can't test.

            regards, tom lane

Hi,

On 2023-05-24 20:34:38 -0400, Tom Lane wrote:
> Thomas Munro <thomas.munro@gmail.com> writes:
> > On Thu, May 25, 2023 at 11:51 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> You'll no doubt be glad to hear that I'll be retiring chickadee
> >> in the very near future.
>
> > . o O { I guess chickadee might have been OK anyway, along with e.g.
> > antique low-end SGI MIPS gear etc of "workstation"/"desktop" form that
> > any collector is likely to have still running, because they only had
> > one CPU (unlike their Vogon-spaceship-sized siblings).  As long as
> > they had 64 bit load/store instructions, those couldn't be 'divided'
> > by an interrupt, so scheduler switches shouldn't be able to tear them,
> > AFAIK? }
>
> PA-RISC can probably do tear-free 8-byte reads, but Andres also
> wanted to raise the bar enough to include 32-bit atomic instructions,
> which PA-RISC hasn't got; the one such instruction it has is
> limited enough that you can't do much beyond building a spinlock.

Yes, I looked at some point, and it didn't seem viable to do more.


> I think there's still some interest in not-antique 32-bit MIPS; I have some
> current-production routers with such CPUs.  (Sadly, they don't have enough
> storage to do anything useful with, or I'd think about repurposing one for
> buildfarm.)

After spending a bunch more time staring at various reference manuals, it
looks to me like 32bit MIPS supports 64 bit atomics these days, via LLWP /
SCWP.

https://s3-eu-west-1.amazonaws.com/downloads-mips/documents/MD00086-2B-MIPS32BIS-AFP-6.06.pdf
documents them as having been added to MIPS32 Release 6, from 2014.

Greetings,

Andres Freund

On Thu, May 25, 2023 at 12:34 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Dunno about antique MIPS.  I think there's still some interest in
> not-antique 32-bit MIPS; I have some current-production routers
> with such CPUs.  (Sadly, they don't have enough storage to do
> anything useful with, or I'd think about repurposing one for
> buildfarm.)

FWIW "development of the MIPS architecture has ceased"[1].  (Clearly
there are living ISAs that continue either its spirit or its ...
instructions, but they aren't calling themselves MIPS.)

[1] https://en.wikipedia.org/wiki/MIPS_architecture