Re: [PATCH] Use MAP_HUGETLB where supported (v3)

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Christian Kruse <christian(at)2ndQuadrant(dot)com>
Cc: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Andres Freund <andres(at)2ndQuadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Use MAP_HUGETLB where supported (v3)
Date: 2014-03-03 19:03:06
Message-ID: 5314D1EA.8020007@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 03/03/2014 11:34 AM, Christian Kruse wrote:
> Hi,
>
>>> Attached is a patch with the updated documentation (now uses
>>> consistently huge pages) as well as a renamed GUC, consistent wording
>>> (always use huge pages) as well as renamed variables.
>>
>> Hmm, I wonder if that could now be misunderstood to have something to do
>> with the PostgreSQL page size? Maybe add the word "memory" or "operating
>> system" in the first sentence in the docs, like this: "Enables/disables the
>> use of huge memory pages".
>
> Accepted, see attached patch.

Thanks, committed!

I spotted this in section "17.4.1 Shared Memory and Semaphores":

> Linux
>
> The default maximum segment size is 32 MB, and the default maximum total size is 2097152 pages. A page is almost always 4096 bytes except in unusual kernel configurations with "huge pages" (use getconf PAGE_SIZE to verify).

It's not any more wrong now than it's always been, but I don't think
huge pages ever affect PAGE_SIZE... Could I cajole you into rephrasing
that, too?

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-03-03 19:05:10 Re: UNION ALL on partitioned tables won't use indices.
Previous Message Noah Misch 2014-03-03 18:58:46 Re: ALTER TABLE lock strength reduction patch is unsafe