Re: Doc tweak for huge_pages?

On Sat, Dec 2, 2017 at 4:08 AM, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> On 11/30/17 23:35, Thomas Munro wrote:
>> On Fri, Dec 1, 2017 at 5:04 PM, Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
>>> On Fri, Dec 01, 2017 at 04:01:24PM +1300, Thomas Munro wrote:
>>>> Hi hackers,
>>>>
>>>> The manual implies that only Linux can use huge pages. That is not
>>>> true: FreeBSD, Illumos and probably others support larger page sizes
>>>> using transparent page coalescing algorithms. On my FreeBSD box
>>>> procstat -v often shows PostgreSQL shared buffers in "S"-flagged
>>>> memory. I think we should adjust the manual to make clear that it's
>>>> the *explicit request for huge pages* that is supported only on Linux
>>>> (and hopefully soon Windows). Am I being too pedantic?
>>>
>>> I suggest to remove "other" and include Linux in the enumeration, since it also
>>> supports "transparent" hugepages.
>>
>> Hmm. Yeah, it does, but apparently it's not so transparent. So if we
>> mention that we'd better indicate in the same paragraph that you
>> probably don't actually want to use it. How about the attached?
>
> Part of the confusion is that the huge_pages setting is only for shared
> memory, whereas the kernel settings affect all memory.

Right. And more specifically, just the main shared memory area, not
DSM segments. Updated to make this point.

(I have wondered whether DSM segments should respect this GUC: it
seems plausible that they should when the size is a multiple of the
huge page size, so that very large DSA areas finish up mostly backed
by huge pages, so that very large shared hash tables would benefit
from lower TLB miss rates. I have only read in an academic paper that
this is a good idea, I haven't investigated whether that would really
help us in practice, and the first problem is that Linux shm_open
doesn't support huge pages anyway so you've need one of the other DSM
implementation options which are currently non-default.)

> Is the same true
> for the proposed Windows patch?

Yes. It adds a flag to the request for the main shared memory area
(after jumping through various permissions hoops).

--
Thomas Munro
http://www.enterprisedb.com