From: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
---|---|
To: | Richard Poole <richard(at)2ndQuadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: patch: add MAP_HUGETLB to mmap() where supported (WIP) |
Date: | 2013-09-16 08:15:28 |
Message-ID: | 5236BE20.6040904@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 14.09.2013 02:41, Richard Poole wrote:
> The attached patch adds the MAP_HUGETLB flag to mmap() for shared memory
> on systems that support it. It's based on Christian Kruse's patch from
> last year, incorporating suggestions from Andres Freund.
I don't understand the logic in figuring out the pagesize, and the
smallest supported hugepage size. First of all, even without the patch,
why do we round up the size passed to mmap() to the _SC_PAGE_SIZE?
Surely the kernel will round up the request all by itself. The mmap()
man page doesn't say anything about length having to be a multiple of
pages size.
And with the patch, why do you bother detecting the minimum supported
hugepage size? Surely the kernel will choose the appropriate hugepage
size just fine on its own, no?
> It is still WIP as there are a couple of points that Andres has pointed
> out to me that haven't been addressed yet;
Which points are those?
I wonder if it would be better to allow setting huge_tlb_pages=try even
on platforms that don't have hugepages. It would simply mean the same as
'off' on such platforms.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Boszormenyi Zoltan | 2013-09-16 08:39:52 | Re: UNNEST with multiple args, and TABLE with multiple funcs |
Previous Message | Alexander Korotkov | 2013-09-16 08:05:06 | Re: GIN improvements part 1: additional information |