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
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 |