| From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Greg Burd <greg(at)burd(dot)me>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(at)eisentraut(dot)org>, Dave Cramer <davecramer(at)gmail(dot)com> |
| Subject: | Re: [PATCH] Fix ARM64/MSVC atomic memory ordering issues on Win11 by adding explicit DMB ?barriers |
| Date: | 2025-12-17 01:57:14 |
| Message-ID: | CA+hUKG+-ESmkaDZ4a_S--UoJ2soVRgsa6uem7REM7LuYxk5xFg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Dec 17, 2025 at 10:40 AM Nathan Bossart
<nathandbossart(at)gmail(dot)com> wrote:
> Hm. I think the USE_LLVM_BACKPORT_SECTION_MEMORY_MANAGER thing might need
> work, too. We don't have any Windows buildfarm machines with LLVM enabled,
> but IIUC it should be possible. Perhaps we can add that to unicorn.
The LLVM code has never run on Windows and will likely need
patching... I know of at least one change required and will write
about that.
> > Also, while the patch
> > is targeting Windows 11 (IIUC), there are some notes in the docs that give
> > the impression Windows 10 is supported, too [0]. I could easily change it
> > to say that AArch64 requires Windows 11, but I don't know what to do with
> > the references to specific versions of Visual Studio and the Windows SDK.
>
> Actually, I'm not sure there's anything specific to Windows 11 in this
> patch, besides perhaps the choice to set USE_ARMV8_CRC32C unconditionally.
> I don't know how likely it is that someone will try to run Postgres on
> Windows on an AArch64 machine without CRC extension support, though.
Assuming you haven't blocked OS updates, Windows stopped booting on
pre-ARMv8.1 hardware a while back. RPi4's Broadcom chip and the
Snapdragon 835 (found in the oldest Windows laptops, according to a
quick Google search) are ARMv8-A only, but did actually have the CRC32
instructions, so it would actually work anyway. They also have the
optional NEON SIMD stuff, which we use unconditionally:
/*
* We use the Neon instructions if the compiler provides access to them (as
* indicated by __ARM_NEON) and we are on aarch64. While Neon support is
* technically optional for aarch64, it appears that all available 64-bit
* hardware does have it. Neon exists in some 32-bit hardware too, but we
* could not realistically use it there without a run-time check, which seems
* not worth the trouble for now.
*/
A single chip in this report lacked FEAT_CRC32, the X-Gene 1 from 2012:
https://gpages.juszkiewicz.com.pl/arm-socs-table/arm-socs.html
So I don't think it's worth worrying about, I was just mentioning the
"Windows 11 requires CRC32, Windows 10 is dead" thing to avoid Greg
being forced to waste time researching the missing feature test code
:-) The reason Windows can't boot on old ARM chips probably has more
to do with the modern atomics needed for decent lock performance,
which every kernel wants.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2025-12-17 02:48:44 | Re: Change the signature of pgstat_report_vacuum() so that it's passed a Relation |
| Previous Message | Robert Haas | 2025-12-17 01:38:01 | Re: [PATCH] Allow complex data for GUC extra. |