Re: [PATCH] Use MAP_HUGETLB where supported (v3) - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: [PATCH] Use MAP_HUGETLB where supported (v3)
Date
Msg-id 5314D1EA.8020007@vmware.com
Whole thread Raw
In response to Re: [PATCH] Use MAP_HUGETLB where supported (v3)  (Christian Kruse <christian@2ndQuadrant.com>)
Responses Re: [PATCH] Use MAP_HUGETLB where supported (v3)  (Christian Kruse <christian@2ndQuadrant.com>)
List 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
always4096 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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: UNION ALL on partitioned tables won't use indices.
Next
From: Kevin Grittner
Date:
Subject: Re: integrate pg_upgrade analyze_new_cluster.sh into vacuumdb