| From: | Christian Kruse <christian(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
| Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, Andres Freund <andres(at)2ndQuadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Abhijit Menon-Sen <ams(at)2ndQuadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: [PATCH] Use MAP_HUGETLB where supported (v3) |
| Date: | 2014-02-27 07:34:48 |
| Message-ID: | 20140227073448.GA24373@defunct.ch |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 26/02/14 13:13, Alvaro Herrera wrote:
>
> There's one thing that rubs me the wrong way about all this
> functionality, which is that we've named it "huge TLB pages". That is
> wrong -- the TLB pages are not huge. In fact, as far as I understand,
> the TLB doesn't have pages at all. It's the pages that are huge, but
> those pages are not TLB pages, they are just memory pages.
I didn't think about this, yet, but you are totally right.
> Since we haven't released any of this, should we discuss renaming it to
> just "huge pages"?
Attached is a patch with the updated documentation (now uses
consistently huge pages) as well as a renamed GUC, consistent wording
(always use huge pages) as well as renamed variables.
Should I create a new commit fest entry for this and delete the old
one? Or should this be done in two patches? Locally in my repo this is
done with two commits, so it would be easy to split that.
Best regards,
--
Christian Kruse http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| Attachment | Content-Type | Size |
|---|---|---|
| huge_tlb_docs_with_renamed_guc_and_variables.patch | text/x-diff | 10.4 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christian Kruse | 2014-02-27 07:35:32 | Re: [PATCH] Use MAP_HUGETLB where supported (v3) |
| Previous Message | Ashutosh Bapat | 2014-02-27 04:55:54 | Re: Avoiding deeply nested AND/OR trees in the parser |