Skip site navigation (1) Skip section navigation (2)

huge tlb support

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Josh Berkus <josh(at)agliodbs(dot)com>
Subject: huge tlb support
Date: 2012-07-03 02:49:10
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On Fri, Jun 29, 2012 at 3:52 PM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> Hi All,
> In a *very* quick patch I tested using huge pages/MAP_HUGETLB for the mmap'ed
> memory.
> That gives around 9.5% performance benefit in a read-only pgbench run (-n -S -
> j 64 -c 64 -T 10 -M prepared, scale 200, 6GB s_b, 8 cores, 24GB mem).
> It also saves a bunch of memory per process due to the smaller page table
> (shared_buffers 6GB):
> cat /proc/$pid_of_pg_backend/status |grep VmPTE
> VmPTE:      6252 kB
> vs
> VmPTE:        60 kB
> Additionally it has the advantage that top/ps/... output under linux now looks
> like:
> 10603 andres    20   0 6381m 4924 1952 R    21  0.0   0:28.04 postgres
> i.e. RES now actually shows something usable... Which is rather nice imo.
> I don't have the time atm into making this something useable, maybe somebody
> else want to pick it up? Looks pretty worthwile investing some time.
> Because of the required setup we sure cannot make this the default but...

So, considering that there is required setup, it seems that the
obvious thing to do here is add a GUC: huge_tlb_pages (boolean).

The other alternative is to try with MAP_HUGETLB and, if it fails, try
again without MAP_HUGETLB.


Robert Haas
The Enterprise PostgreSQL Company


pgsql-hackers by date

Next:From: Bruce MomjianDate: 2012-07-03 02:51:41
Subject: Re: Posix Shared Mem patch
Previous:From: Alvaro HerreraDate: 2012-07-03 02:44:00
Subject: Re: File format for SSL CRL file

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group