Re: Report: Linux huge pages with Postgres - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: Report: Linux huge pages with Postgres
Date
Msg-id 1290971701.4634.924.camel@ebony
Whole thread Raw
In response to Re: Report: Linux huge pages with Postgres  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Report: Linux huge pages with Postgres
List pgsql-hackers
On Sun, 2010-11-28 at 12:04 -0500, Tom Lane wrote:
> Simon Riggs <simon@2ndQuadrant.com> writes:
> > On Sat, 2010-11-27 at 14:27 -0500, Tom Lane wrote:
> >> This is discouraging; it certainly doesn't make me want to expend the
> >> effort to develop a production patch.
> 
> > Perhaps.
> 
> > Why do this only for shared memory?
> 
> There's no exposed API for causing a process's regular memory to become
> hugepages.

We could make all the palloc stuff into shared memory also ("private"
shared memory that is). We're not likely to run out of 64-bit memory
addresses any time soon.

> > Surely the majority of memory
> > accesses are to private memory, so being able to allocate private memory
> > in a single huge page would be better for avoiding TLB cache misses.
> 
> It's not really about the number of memory accesses, it's about the
> number of TLB entries needed.  Private memory is generally a lot smaller
> than shared, in a tuned PG installation.

Sure, but 4MB of memory is enough to require 1000 TLB entries, which is
more than enough to blow the TLB even on a Nehalem. So the size of the
memory we access is already big enough to blow the cache, even without
shared buffers. If the majority of accesses are from private memory then
the TLB cache will already be thrashed by the time we access shared
buffers again.

That is at least one possible explanation for the lack of benefit.

-- Simon Riggs           http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Report: Linux huge pages with Postgres
Next
From: Tom Lane
Date:
Subject: Re: Report: Linux huge pages with Postgres