Re: Improve logging when using Huge Pages

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Justin Pryzby <pryzby(at)telsasoft(dot)com>
Cc: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, sfrost(at)snowman(dot)net, alvherre(at)alvh(dot)no-ip(dot)org, andres(at)anarazel(dot)de, nathandbossart(at)gmail(dot)com, jchampion(at)timescale(dot)com, john(dot)naylor(at)enterprisedb(dot)com, masao(dot)fujii(at)oss(dot)nttdata(dot)com, noriyoshi(dot)shinoda(at)hpe(dot)com, pgsql-hackers(at)postgresql(dot)org, rjuju123(at)gmail(dot)com, sawada(dot)mshk(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, thomas(dot)munro(at)gmail(dot)com
Subject: Re: Improve logging when using Huge Pages
Date: 2023-03-28 00:35:30
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Thu, Mar 23, 2023 at 08:50:50PM -0500, Justin Pryzby wrote:
> I'm sure it's possible, but it's also not worth writing a special
> implementation just to handle huge_pages_active, which is better written
> in 30 lines than in 300 lines.
> If we needed to avoid using a GUC, maybe it'd work to add
> huge_pages_active to PGShmemHeader. But "avoid using gucs at all costs"
> isn't the goal, and using a GUC parallels all the similar, and related
> things without needing to allocate extra bits of shared_memory.

Yeah, I kind of agree that the complications are not appealing
compared to the use case. FWIW, I am fine with just using "unknown"
even under -C because we don't know the status without the mmpa()
call. And we don't want to assign what would be potentially a bunch
of memory when running that.

> This goes back to using a GUC, and:
> - removes GUC_RUNTIME_COMPUTED, since that causes a useless error when
> using -C if the server is running, rather than successfully printing
> "unknown".
> - I also renamed it from huge_pages_active = {true,false,unknown} to
> huge_pages_STATUS = {on,off,unknown}. This parallels huge_pages,
> which is documented to accept values on/off/try. Also, true/false
> isn't how bools are displayed.
> - I realized that the rename suggested implementing it as an enum GUC,
> and re-using the existing HUGE_PAGES_{ON,OFF} values (and adding an
> "UNKNOWN"). Maybe this also avoids Stephen's earlier objection to
> using a string ?

huge_pages_status is OK here, as is reusing the enum struct to avoid
an unnecessary duplication.

> I mis-used cirrusci to check that the GUC does work correctly under
> windows.

You mean that you abused of it in some custom branch running the CI on
github? If I may ask, what did you do to make sure that huge pages
are set when re-attaching a backend to a shmem area?

> If there's continuing aversions to using a GUC, please say so, and try
> to suggest an alternate implementation you think would be justified.
> It'd need to work under windows with EXEC_BACKEND.

Looking at the patch, it seems like that this should work even for
EXEC_BACKEND on *nix when a backend reattaches.. It may be better to
be sure of that, as well, if it has not been tested.

+++ b/src/backend/port/win32_shmem.c
@@ -327,6 +327,10 @@ retry:
+ SetConfigOption("huge_pages_status", (flProtect & SEC_LARGE_PAGES) ?

Perhaps better to just move that at the end of PGSharedMemoryCreate()
for WIN32?

+ <varlistentry id="guc-huge-pages-status" xreflabel="huge_pages_status">
+ <term><varname>huge_pages_status</varname> (<type>enum</type>)
+ <indexterm>
+ <primary><varname>huge_pages_status</varname> configuration parameter</primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>
+ Reports the state of huge pages in the current instance.
+ See <xref linkend="guc-huge-pages"/> for more information.
+ </para>
+ </listitem>
+ </varlistentry>

The patch needs to provide more details about the unknown state, IMO,
to make it crystal-clear to the users what are the limitations of this
GUC, especially regarding the fact that this is useful when "try"-ing
to allocate huge pages, and that the value can only be consulted after
the server has been started.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Geoghegan 2023-03-28 01:07:09 Re: Add pg_walinspect function with block info columns
Previous Message Michael Paquier 2023-03-28 00:13:10 Re: ALTER TABLE SET ACCESS METHOD on partitioned tables