Re: munmap() failure due to sloppy handling of hugepage size

Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
> > On October 12, 2016 1:25:54 PM PDT, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> A little bit of research suggests that on Linux the thing to do would
> >> be to get the actual default hugepage size by reading /proc/meminfo and
> >> looking for a line like "Hugepagesize: 2048 kB".
>
> > We had that, but Heikki ripped it out when merging... I think you're supposed to use /sys to get the available size.
>
> According to
> https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt
> looking into /proc/meminfo is the longer-standing API and thus is
> likely to work on more kernel versions. Also, if you look into
> /sys then you are going to see multiple possible values and it's
> not clear how to choose the right one.

I'm not sure that this is the best rationale. In my system there are
2MB and 1GB huge page sizes; in systems with lots of memory (let's say 8
GB of shared memory is requested) it seems a clear winner to allocate 8
1GB hugepages than 4096 2MB hugepages because the page table is so much
smaller. The /proc interface only shows the 2MB page size, so if we go
that route we'd not be getting the full benefit of the feature.

We could just fall back to reading /proc if we cannot find the /sys
stuff; that makes it continue to work on older kernels.

Regarding choosing one among several size choices, I'd think the larger
huge page size is always better if the request size is at least that
large, otherwise fall back to the next smaller one. (This could stand
some actual research).

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services