Re: patch: add MAP_HUGETLB to mmap() where supported (WIP)

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

In response to

Responses

Browse pgsql-hackers by date

  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