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

From Abhijit Menon-Sen
Subject Re: [PATCH] Use MAP_HUGETLB where supported (v3)
Date
Msg-id 20131030072833.GG4183@toroid.org
Whole thread Raw
In response to Re: [PATCH] Use MAP_HUGETLB where supported (v3)  (David Fetter <david@fetter.org>)
List pgsql-hackers
At 2013-10-30 00:10:39 -0700, david@fetter.org wrote:
>
> How about documenting that 2MB is the quantum (OK, we'll say
> "indivisible unit" or "smallest division" or something) and failing
> with a message to that effect if someone tries to set it otherwise?

I don't think you understand the problem. We're not discussing a user
setting here. The size that is passed to PGSharedMemoryCreate is based
on shared_buffers and our estimates of how much memory we need for other
things like ProcArray (see ipci.c:CreateSharedMemoryAndSemaphores).

If this calculated size is not a multiple of a page size supported by
the hardware (usually 2/4/16MB etc.), the allocation will fail under
some commonly-used kernels. We can either ignore the problem and let
the allocation fail, or try to discover the smallest supported huge
page size (what the patch does now), or assume that 2MB pages can be
used if any huge pages can be used and align accordingly.

We could use a larger size, e.g. if we aligned to 16MB then it would
work on hardware that supported 2/4/8/16MB pages, but we'd waste the
extra memory unless we also increased NBuffers after the rounding up
(which is also something Andres suggested earlier).

I don't have a strong opinion on the available options, other than not
liking the "do nothing" approach.

-- Abhijit



pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: [PATCH] Use MAP_HUGETLB where supported (v3)
Next
From: Leonardo Francalanci
Date:
Subject: Re: Fast insertion indexes: why no developments