Alvaro Herrera <alvhe...@2ndquadrant.com> writes: > Tom Lane wrote: >> 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. And you'll tell mmap() which one to do how exactly? I haven't found anything explaining how applications get to choose which page size applies to their request. The kernel document says that /proc/meminfo reflects the "default" size, and I'd assume that that's what we'll get from mmap. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers