Date: Thu, 31 Mar 2022 12:59:08 +0800
From: Julien Rouhaud <rjuju123@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: Thomas Munro <thomas.munro@gmail.com>, okano.naoki@jp.fujitsu.com,
	PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #17448: In Windows 10, version 1703 and later, huge_pages
 doesn't work.
Message-ID: <20220331045908.bm5edcacvymgwwv2@jrouhaud>
References: <17448-0a96583a67edb1f7@postgresql.org>
 <Yj6oxYsBE5LXA8ZP@paquier.xyz>
 <20220326082408.moh55zuecxjmewnm@jrouhaud>
 <CA+hUKGLwOSf-QwVtCcKx9xvugN2BSzEBBeD5DNyTXgcSRp5sTw@mail.gmail.com>
 <YkQMyhsP7xgLDDT/@paquier.xyz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <YkQMyhsP7xgLDDT/@paquier.xyz>
Archived-At: 
 <https://www.postgresql.org/message-id/20220331045908.bm5edcacvymgwwv2%40jrouhaud>
Precedence: bulk

Hi,

On Wed, Mar 30, 2022 at 04:54:50PM +0900, Michael Paquier wrote:
> On Sun, Mar 27, 2022 at 12:07:57AM +1300, Thomas Munro wrote:
> > There are traces of method to the madness:  It's basically YYMM, but
> > then after 2004 they switched to H1 and H2 (first/second half of the
> > year) instead of MM, perhaps to avoid confusion with YYYY format year.
> > Note also that Windows 10 has a 21H2 and Windows 11 has a 21H2.
> >
> > Some question I have: is FILE_MAP_LARGE PAGES a macro?  We claim to
> > support all those ancient zombie OSes like Windows 7, or maybe it's
> > even XP for 11, and this has to be back-patched to 11, so we might
> > need to make it conditional.  But conditional on what?  For example,
> > does something like the attached work (untested)?  What happens if a <
> > 1703 kernel sees this flag, does it reject it or ignore it?
>
> I don't have an answer about how much Windows gets angry if we pass
> down to MapViewOfFileEx() the flag FILE_MAP_LARGE_PAGES when running
> the code on a version of Windows that does not support it.

No idea either, and I don't have old enough Windows machine available to try.

> Anyway, I think that we could just play it safe.  See for example the
> attached, where I use PG_FILE_MAP_LARGE_PAGES at compile time to find
> if the value is set.  Then, at run-time, I am just relying on
> IsWindowsVersionOrGreater() to do the job, something useful when
> huge_pages=on as I guess we should fail hard if we did not know about
> FILE_MAP_LARGE_PAGES at compile-time, but try to use huge pages at run
> time with version >= 10.0.1703.

That approach seems sensible.  For reference the versionhelpers.h seems to be
available starting with VS 2013 / v120, which is ok since that the oldest
version we support AFAICS.

After *a lot of time* I could finally test this patch.  For the record I could
never find a way to allow 'Lock pages in memory' on the Windows 10 home I have,
so I tried on my Windows 11 evaluation I also had around (version 21H2, so it
should be recent enough).  For the record on this one there was gpedit
available, but then I got a 1450 error, and didn't find any information on how
to reserve huge pages or something like that on Windows.  So I just configured
shared_buffers to 10MB, which should still be big enough to need multiple huge
pages, and it seems to work:

postgres=# select version();
                            version
---------------------------------------------------------------
 PostgreSQL 15devel, compiled by Visual C++ build 1929, 64-bit
(1 row)

postgres=# show huge_pages;
 huge_pages
------------
 on
(1 row)

Now, I also have the exact same result without the patch applied so it's hard
to know whether it had any impact at all.  Unfortunately, I didn't find any
information on how to check if "large pages" are used and/or by which program.