Re: BUG #17448: In Windows 10, version 1703 and later, huge_pages doesn't work.

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, okano(dot)naoki(at)jp(dot)fujitsu(dot)com, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #17448: In Windows 10, version 1703 and later, huge_pages doesn't work.
Date: 2022-03-31 04:59:08
Message-ID: 20220331045908.bm5edcacvymgwwv2@jrouhaud
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-bugs pgsql-hackers


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();
PostgreSQL 15devel, compiled by Visual C++ build 1929, 64-bit
(1 row)

postgres=# show huge_pages;
(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.

In response to


Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2022-03-31 07:42:37 Re: BUG #17448: In Windows 10, version 1703 and later, huge_pages doesn't work.
Previous Message Pierre Forstmann 2022-03-30 19:07:40 Re: BUG #17393: Delete database after recovery with point-in-time is still missing datafiles

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-03-31 04:59:15 Re: Removing more vacuumlazy.c special cases, relfrozenxid optimizations
Previous Message Kyotaro Horiguchi 2022-03-31 04:58:45 Re: In-placre persistance change of a relation