Re: Supporting huge pages on Windows

From: Amit Kapila [mailto:amit(dot)kapila16(at)gmail(dot)com]
> > Hmm, the large-page requires contiguous memory for each page, so this
> error could occur on a long-running system where the memory is heavily
> fragmented. For example, please see the following page and check the memory
> with RAMMap program referred there.
> >
>
> I don't have RAMMap and it might take some time to investigate what is going
> on, but I think in such a case even if it works we should keep the default
> value of huge_pages as off on Windows. I request somebody else having
> access to Windows m/c to test this patch and if it works then we can move
> forward.

You are right. I modified the patch so that the code falls back to the non-huge page when CreateFileMapping() fails due to the shortage of large pages. That's what the Linux version does.

The other change is to parameterize the Win32 function names in the messages in EnableLockPagePrivileges(). This is to avoid adding almost identical messages unnecessarily. I followed Alvaro's comment. I didn't touch the two existing sites that embed Win32 function names. I'd like to leave it up to the committer to decide whether to change as well, because changing them might make it a bit harder to apply some bug fixes to earlier releases.

FYI, I could reproduce the same error as Amit on 32-bit Win7, where the total RAM is 3.5 GB and available RAM is 2 GB. I used the attached largepage.c. Immediately after the system boot, I could only allocate 8 large pages. When I first tried to allocate 32 large pages, the test program produced:

large page size = 2097152
allocating 32 large pages...
CreateFileMapping failed: error code = 1450

You can build the test program as follows:

cl largepage.c advapi32.lib

Regards
Takayuki Tsunakawa