]> granicus.if.org Git - postgresql/commit
Try to find out the actual hugepage size when making a MAP_HUGETLB request.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 13 Oct 2016 19:06:46 +0000 (15:06 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 13 Oct 2016 19:07:11 +0000 (15:07 -0400)
commit6d3cbbf5954250638ea5837bf514a6d392f2329e
tree566e147f1e1f7e2685bf22a340d3dd9f7541e125
parent573d2ed0e48fc59e8186a616ce8ba30960a9cec0
Try to find out the actual hugepage size when making a MAP_HUGETLB request.

Even if Linux's mmap() is okay with a partial-hugepage request, munmap()
is not, as reported by Chris Richards.  Therefore it behooves us to try
a bit harder to find out the actual hugepage size, instead of assuming
that we can skate by with a guess.

For the moment, just look into /proc/meminfo to find out the default
hugepage size, and use that.  Later, on kernels that support requests
for nondefault sizes, we might try to consider other alternatives.
But that smells more like a new feature than a bug fix, especially if
we want to provide any way for the DBA to control it, so leave it for
another day.

I set this up to allow easy addition of platform-specific code for
non-Linux platforms, if needed; but right now there are no reports
suggesting that we need to work harder on other platforms.

Back-patch to 9.4 where hugepage support was introduced.

Discussion: <31056.1476303954@sss.pgh.pa.us>
src/backend/port/sysv_shmem.c