From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: munmap() failure due to sloppy handling of hugepage size |
Date: | 2016-10-12 20:33:38 |
Message-ID: | 31426.1476304418@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Vitaly Burovoy | 2016-10-12 20:44:35 | Re: macaddr 64 bit (EUI-64) datatype support |
Previous Message | Vitaly Burovoy | 2016-10-12 20:31:45 | Re: macaddr 64 bit (EUI-64) datatype support |