Feedback-ID: i675e48f3:Fastmail
MIME-Version: 1.0
Date: Wed, 17 Dec 2025 13:34:13 -0500
From: "Greg Burd" <greg@burd.me>
To: "Thomas Munro" <thomas.munro@gmail.com>,
 "Nathan Bossart" <nathandbossart@gmail.com>
Cc: "Andres Freund" <andres@anarazel.de>,
 "PostgreSQL Hackers" <pgsql-hackers@lists.postgresql.org>,
 "Peter Eisentraut" <peter@eisentraut.org>,
 "Dave Cramer" <davecramer@gmail.com>
Message-Id: <2f1e1872-9ab5-4082-bedf-8dee269152c2@app.fastmail.com>
In-Reply-To: 
 <CA+hUKG+-ESmkaDZ4a_S--UoJ2soVRgsa6uem7REM7LuYxk5xFg@mail.gmail.com>
References: <aTw8tb_eIpDBYHfW@nathan>
 <8e926f26-0a97-434f-a665-8bb6f9159b08@app.fastmail.com>
 <sxhkd5ucchq4vululj6xiwkrd6tsxh53gjiku2knjnqalglumc@hs4vp3b7e7by>
 <6646f9f4-3609-41e2-8d9f-dcd63e9f915e@app.fastmail.com>
 <aUB_6ZNFRtjM7FVS@nathan>
 <qu3uuja2u3uerwmbhvz6pscdhlhdm3xa3d4nc7lr7vvpowarzl@yn45ne6635ml>
 <aUCTH8oP4Wj4r58P@nathan> <B9B3413D-8570-46C3-8CCA-0C56E761AE7D@anarazel.de>
 <b3c0626c-2851-46d2-9fae-23d685632d5c@app.fastmail.com>
 <aUGf5oyzguybiUBB@nathan> <aUHR3eSjkaBjaUAB@nathan>
 <CA+hUKG+-ESmkaDZ4a_S--UoJ2soVRgsa6uem7REM7LuYxk5xFg@mail.gmail.com>
Subject: Re: [PATCH] Fix ARM64/MSVC atomic memory ordering issues on Win11 by
 adding
 explicit DMB ?barriers
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/2f1e1872-9ab5-4082-bedf-8dee269152c2%40app.fastmail.com>
Precedence: bulk


On Tue, Dec 16, 2025, at 8:57 PM, Thomas Munro wrote:
> On Wed, Dec 17, 2025 at 10:40=E2=80=AFAM Nathan Bossart
> <nathandbossart@gmail.com> wrote:

Hey Nathan, Thomas, thanks for your continued investment of time in this=
 patch.  More thoughts below, but I wonder if the thing to do is to comm=
it this and then for me to follow-on with a few more targeted changes to=
 round out this platform combo?

>> 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 en=
abled,
>> 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.

I think it would be amazing to support this eventually, but as I'm not a=
 MSVC or Win11 guru this feels like a longer term patch.  I'm still stru=
ggling with simpler things at the moment.  The platform is not well esta=
blished so some libraries are missing or out of date.  There's no ARM64-=
native Perl either.

>> > Also, while the patch
>> > is targeting Windows 11 (IIUC), there are some notes in the docs th=
at give
>> > the impression Windows 10 is supported, too [0].  I could easily ch=
ange it
>> > to say that AArch64 requires Windows 11, but I don't know what to d=
o with
>> > the references to specific versions of Visual Studio and the Window=
s SDK.

When I get a chance I'll post a docs patch for debate/review.

>> Actually, I'm not sure there's anything specific to Windows 11 in this
>> patch, besides perhaps the choice to set USE_ARMV8_CRC32C uncondition=
ally.
>> 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 the=
m (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, bu=
t we
>  * could not realistically use it there without a run-time check, whic=
h 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.

I think there are a few things to offer up in the next few weeks:
* docs
* popcnt
* SIMD
* wiki page with HOWTO info for the next "brave" soul to give this a go
* what else?

What this patch does is get "unicorn" off the dead list, which would be =
nice.

-greg