On Monday, July 09, 2012 08:11:00 AM Tom Lane wrote:
> y...@mwd.biglobe.ne.jp (YAMAMOTO Takashi) writes:
> >> Also, I was under the impression that recent Linux kernels use hugepages
> >> automatically if they can, so I wonder exactly what Andres was testing
> >> on ...
> >
> > if you mean the "trasparent hugepage" feature, iirc it doesn't affect
> > MAP_SHARED mappings like this.
>
> Oh! That would explain some things. It seems like a pretty nasty
> restriction though ... do you know why they did that?
Looking a bit deeper they explicitly only work on private memory. The reason
apparently being that its too hard to update the page table entries in
multiple processes at once without introducing locking problems/scalability
issues.
To be sure one can check /proc/$pid_of_pg_proccess/smaps and look for the
mapping to /dev/zero or the biggest mapping ;). Its not counted as Anonymous
memory and it doesn't have transparent hugepages. I was confused before
because there is quite some (400mb here) huge pages allocated for postgres
during a pgbench run but thats just all the local memory...
Greetings,
Andres
PS: The important #define is in mm/huge_memory.c:
#define VM_NO_THP (VM_SPECIAL|VM_INSERTPAGE|VM_MIXEDMAP|VM_SAO| \
VM_HUGETLB|VM_SHARED|VM_MAYSHARE)
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
