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 11:03:09
Message-ID: 20220331110309.ws25d6dl5yyzprye@jrouhaud
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

On Thu, Mar 31, 2022 at 06:46:59PM +0800, Julien Rouhaud wrote:
> On Thu, Mar 31, 2022 at 04:00:55PM +0800, Julien Rouhaud wrote:
> > > Okano-san has mentioned VMMap upthread:
> > > https://docs.microsoft.com/en-us/sysinternals/downloads/vmmap
> >
> > Yes, I totally missed that. Thomas Munro also mentioned it off-list, and
> > also found some reference [1] indicating that large pages should show up as
> > "Locked WS". I tested with and without the patch and in both case I don't see
> > any "Locked WS" usage. I also get the same Page Table size, which seems
> > consistent with large pages not being used. Now, this is a vm running with
> > virtualbox and we're not entirely sure that huge pages can be allocated with
> > it. I wish I could test on my windows 10 machine as it's not virtualized, but
> > I can't give the required privileges.
> >
> > [1] https://aloiskraus.wordpress.com/2016/10/03/windows-10-memory-compression-and-more/
>
> So, after more digging it turns out that the patch is supposed to work. If I
> force using the PG_FILE_MAP_LARGE_PAGES, postgres starts and I do see "Locked
> WS" usage with VMMap, with a size in the order of magnitude of my
> shared_buffers.
>
> What is apparently not working on my VM is IsWindowsVersionOrGreater(10, 0,
> 1703). I added some debug around to check what GetVersionEx() [2] is saying,
> and I get:
>
> dwMajorVersion == 6
> dwMinorVersion == 2
> dwBuildNumber == 9200
>
> While winver.exe on the same vm says windows 11, version 21H2, build 22000.493.

So, what GetVersionEx returns is actually "it depends", and this is documented:

> With the release of Windows 8.1, the behavior of the GetVersionEx API has
> changed in the value it will return for the operating system version. The
> value returned by the GetVersionEx function now depends on how the
> application is manifested.
>
> Applications not manifested for Windows 8.1 or Windows 10 will return the
> Windows 8 OS version value (6.2). Once an application is manifested for a
> given operating system version, GetVersionEx will always return the version
> that the application is manifested for in future releases. To manifest your
> applications for Windows 8.1 or Windows 10, refer to Targeting your
> application for Windows.

There's no such indication on IsWindowsVersionOrGreater(), but after seeing
various comments on forums from angry people, it may be a hint that it behaves
similarly. I'm not sure what to do at this point, maybe just always use the
flag (the PG_ version which may be 0), hoping that hopefully windows won't
define it if it can't handle it?

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Sergey Belyashov 2022-03-31 12:53:27 Re: BUG #17438: Logical replication hangs on master after huge DB load
Previous Message Julien Rouhaud 2022-03-31 10:46:59 Re: BUG #17448: In Windows 10, version 1703 and later, huge_pages doesn't work.

Browse pgsql-hackers by date

  From Date Subject
Next Message Matthias van de Meent 2022-03-31 11:09:06 Re: Commitfest Update
Previous Message Alvaro Herrera 2022-03-31 10:56:20 Re: Commitfest Update