From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
Cc: | Julien Rouhaud <rjuju123(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-30 07:54:50 |
Message-ID: | YkQMyhsP7xgLDDT/@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs pgsql-hackers |
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.
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.
Perhaps there is a better thing to do?
--
Michael
Attachment | Content-Type | Size |
---|---|---|
win32-hugepages-michael.patch | text/x-diff | 2.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Lorenz, Christopher | 2022-03-30 11:49:49 | AW: BUG #17393: Delete database after recovery with point-in-time is still missing datafiles |
Previous Message | Amit Kapila | 2022-03-29 12:07:13 | Re: Logical replication stops dropping used initial-sync replication slots |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2022-03-30 08:30:01 | Re: logical replication empty transactions |
Previous Message | wangw.fnst@fujitsu.com | 2022-03-30 07:54:16 | RE: Logical replication timeout problem |