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

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2016-10-12 16:33:38 -0400, Tom Lane wrote:
>> 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.

> That's a fair point. It'd probably be good to use the largest we can,
> bounded by a percentage of max waste or such. But that's likely
> something for another day.

Yeah. Merlin pointed out that on versions of Linux newer than my
RHEL6 box, mmap accepts additional flag bits that let you specify
which hugepage size to use. So we would need to use those if we
wanted to work with anything besides the default size.

Now AFAICT from the documentation I've seen, configuring hugepages
is all still pretty manual, ie the sysadmin has to set up so many huge
pages of each size at or near boot. So I'm thinking that using a
non-default size should be something that happens only if the user
tells us to, ie we'd need to add a GUC saying "use size X". That's
pretty ugly but if the admin is intending PG to use pages from a
certain pool, how else would we ensure that the right thing happens?
And it'd provide a way of overriding our default 2MB guess on non-Linux
platforms.

Anyway, anything involving a new GUC is certainly new-feature, HEAD-only
material. I think though that reading the default hugepage size out of
/proc/meminfo is a back-patchable bug fix.

regards, tom lane