Thread: Proposal: Removing 32 bit support starting from PG17++
I recently stumbled over the following Intel proposal for dropping 32bit support in x86 processors. [1]
This inspired me to propose dropping 32bit support for PostgreSQL starting with PG17.
It seems obvious that production systems mostly won't use newly installed 32 bit native code in late 2024 and beyond.
A quick inspection of the buildfarm only showed a very limited number of 32bit systems.
This proposal follows the practice for Windows which already (practically) dropped 32bit support.
32bit systems may get continuing support in the backbranches until PG16 retires in 2028.
Even if I am not a postgres hacker I suppose this could simplify things quite a lot.
Any thoughts for discussion are welcome!
Hans Buschmann
[1] https://www.phoronix.com/news/Intel-X86-S-64-bit-Only
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
Attachment
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
>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).
Hello Tom,