Re: [HACKERS] Supporting huge pages on Windows - Mailing list pgsql-hackers

Hi,

I tried to test v8 version of patch. Firstly, I was able to start the
postgresql server process  with 'huge_pages' set to on. I had to
follow the instructions given in MSDN[1] to enable lock pages in
memory option and also had to start the postgresql server process as
admin user.

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

To start with, I ran the regression test-suite and didn't find any
failures. But, then I am not sure if huge_pages are getting used or
not. However, upon checking the settings for huge_pages and I found it
as 'on'. I am assuming, if huge pages is not being used due to
shortage of large pages, it should have fallen back to non-huge pages.

I also ran the pgbench tests on read-only workload and here are the
results I got.

pgbench -c 4 -j 4 - T 600 bench

huge_pages=on, TPS = 21120.768085
huge_pages=off, TPS = 20606.288995

[1] - https://msdn.microsoft.com/en-IN/library/ms190730.aspx

--
With Regards,
Ashutosh Sharma
EnterpriseDB:http://www.enterprisedb.com

On Thu, Feb 23, 2017 at 12:59 PM, Tsunakawa, Takayuki
<tsunakawa.takay@jp.fujitsu.com> wrote:
> From: Amit Kapila [mailto:amit.kapila16@gmail.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
dueto 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
toavoid adding almost identical messages unnecessarily.  I followed Alvaro's comment.  I didn't touch the two existing
sitesthat embed Win32 function names.  I'd like to leave it up to the committer to decide whether to change as well,
becausechanging 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
firsttried 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
>
>
>
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>