Re: [PATCH] Add support for choosing huge page size - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: [PATCH] Add support for choosing huge page size
Date
Msg-id CA+hUKGJYp73fiH=8-qbPCj3jXkQKy+ChwyQr7KiZg8ZUU4R9JQ@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Add support for choosing huge page size  (Odin Ugedal <odin@ugedal.com>)
List pgsql-hackers
On Mon, Jun 22, 2020 at 7:51 AM Odin Ugedal <odin@ugedal.com> wrote:
> Ahh, thanks. Looks like the Windows stuff isn't autogenerated, so
> maybe this new patch works..

On second thoughts, it seemed like overkill to use configure just to
detect whether macros are defined, so I dropped that and used plain
old #if defined().  I also did some minor proof-reading and editing on
the documentation and comments; I put back the bit about sysctl and
sysctl.conf because I think that is still pretty useful to highlight
for people who just want to use the default size, along with the /sys
method.

Pushed.  Thanks for the patch!  It's always nice to see notes like
this being removed:

- * Currently *mmap_flags is always just MAP_HUGETLB.  Someday, on systems
- * that support it, we might OR in additional bits to specify a particular
- * non-default huge page size.

In passing, I think GetHugePageSize() is a bit odd; it claims to have
a Linux-specific part and a generic part, and yet the whole thing is
wrapped in #ifdef MAP_HUGETLB which is Linux-specific as far as I
know.  But that's not this patch's fault.

We might want to consider removing the note about CONFIG_HUGETLB_PAGE
from the manual; I'm not sure if kernels built without that stuff are
still roaming in the wild, or if it's another anachronysm due for
removal like commit c8be915a.  I didn't do that today, though.



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: expose parallel leader in CSV and log_line_prefix
Next
From: Alvaro Herrera
Date:
Subject: Re: expose parallel leader in CSV and log_line_prefix