From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | "Bossart, Nathan" <bossartn(at)amazon(dot)com> |
Cc: | Justin Pryzby <pryzby(at)telsasoft(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Magnus Hagander <magnus(at)hagander(dot)net>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Don Seiler <don(at)seiler(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Estimating HugePages Requirements? |
Date: | 2021-09-01 06:53:52 |
Message-ID: | YS8jgN37QvlrKnzQ@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-hackers |
On Tue, Aug 31, 2021 at 05:37:52AM +0000, Bossart, Nathan wrote:
> I moved the GUC calculation to ipci.c, adjusted the docs, and added a
> huge_pages_required GUC. It's still a little rough around the edges,
> and I haven't tested it on Windows, but this seems like the direction
> the patch is headed.
Hmm. I am not sure about the addition of huge_pages_required, knowing
that we would have shared_memory_size. I'd rather let the calculation
part to the user with a scan of /proc/meminfo.
+#elif defined(WIN32)
+ hp_size = GetLargePageMinimum();
+#endif
+
+#if defined(MAP_HUGETLB) || defined(WIN32)
+ hp_required = (size_b / hp_size) + 1;
As of [1], there is the following description:
"If the processor does not support large pages, the return value is
zero."
So there is a problem here.
[1]: https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-getlargepageminimum
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Bossart, Nathan | 2021-09-01 18:28:21 | Re: Estimating HugePages Requirements? |
Previous Message | Laurenz Albe | 2021-08-31 08:52:10 | Re: vacuumlo |
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2021-09-01 07:26:14 | Re: Converting contrib SQL functions to new style |
Previous Message | Peter Smith | 2021-09-01 06:36:03 | Re: Added schema level support for publication. |