From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Report: Linux huge pages with Postgres |
Date: | 2010-11-28 19:32:04 |
Message-ID: | 8866.1290972724@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On Sun, 2010-11-28 at 12:04 -0500, Tom Lane wrote:
>> 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.
Mph. It's still not going to work well enough to be useful, because the
kernel design for hugepages assumes a pretty static number of them.
That maps well to our use of shared memory, not at all well to process
local memory.
> 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.
That can't possibly be right. I'm sure the chip designers have heard of
programs using more than 4MB.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-11-28 19:38:07 | Re: profiling connection overhead |
Previous Message | Simon Riggs | 2010-11-28 19:15:01 | Re: Report: Linux huge pages with Postgres |