Re: munmap() failure due to sloppy handling of hugepage size - Mailing list pgsql-hackers

From Tom Lane
Subject Re: munmap() failure due to sloppy handling of hugepage size
Date
Msg-id 31426.1476304418@sss.pgh.pa.us
Whole thread Raw
In response to Re: munmap() failure due to sloppy handling of hugepage size  (Andres Freund <andres@anarazel.de>)
Responses Re: munmap() failure due to sloppy handling of hugepage size  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: munmap() failure due to sloppy handling of hugepage size  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On October 12, 2016 1:25:54 PM PDT, Tom Lane <tgl@sss.pgh.pa.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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Vitaly Burovoy
Date:
Subject: Re: macaddr 64 bit (EUI-64) datatype support
Next
From: Vitaly Burovoy
Date:
Subject: Re: macaddr 64 bit (EUI-64) datatype support