RE: Improve logging when using Huge Pages

Shinoda, Noriyoshi <noriyoshi.shinoda@hpe.com>

From: "Shinoda, Noriyoshi (PN Japan FSIP)" <noriyoshi.shinoda@hpe.com>
To: "masao.fujii@oss.nttdata.com" <masao.fujii@oss.nttdata.com>, "Kyotaro Horiguchi" <horikyota.ntt@gmail.com>
Cc: "pryzby@telsasoft.com" <pryzby@telsasoft.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "rjuju123@gmail.com" <rjuju123@gmail.com>, "tgl@sss.pgh.pa.us" <tgl@sss.pgh.pa.us>
Date: 2021-09-20T08:55:13Z
Lists: pgsql-hackers

Attachments

Hi,

Thank you for your comment.

> I was afraid that logging the message like "could not ..." every time when the server starts up would surprise users unnecessarily.
> Because the message sounds like it reports a server error.

Fujii-san, 
I was worried about the same thing as you.
So the attached patch gets the value of the kernel parameter vm.nr_hugepages, 
and if it is the default value of zero, the log level is the same as before. 
On the other hand, if any value is set, the level is set to LOG.
I hope I can find a better message other than this kind of implementation.

Regards,
Noriyoshi Shinoda

-----Original Message-----
From: Kyotaro Horiguchi [mailto:horikyota.ntt@gmail.com] 
Sent: Friday, September 17, 2021 1:15 PM
To: masao.fujii@oss.nttdata.com
Cc: pryzby@telsasoft.com; Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi.shinoda@hpe.com>; pgsql-hackers@postgresql.org; rjuju123@gmail.com; tgl@sss.pgh.pa.us
Subject: Re: Improve logging when using Huge Pages

At Fri, 17 Sep 2021 00:13:41 +0900, Fujii Masao <masao.fujii@oss.nttdata.com> wrote in 
> 
> 
> On 2021/09/08 11:17, Kyotaro Horiguchi wrote:
> > I don't dislike the message, but I'm not sure I like the message is 
> > too verbose, especially about it has DETAILS. It seems to me 
> > something like the following is sufficient, or I'd like see it even 
> > more concise.
> > "fall back anonymous shared memory to non-huge pages: required %zu 
> > bytes for huge pages"
> > If we emit an error message for other than mmap failure, it would be 
> > like the following.
> > "fall back anonymous shared memory to non-huge pages: huge pages not 
> > available"
> 
> How about simpler message like "disabling huge pages" or "disabling 
> huge pages due to lack of huge pages available"?

Honestly, I cannot have conficence on my wording, but "disabling huge pages" souds like somthing that happens on the OS layer.  "did not use/gave up using huge pages for anounymous shared memory" might work well, I'm not sure, though...

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Add GUC parameter "huge_pages_status"

  2. Add check on initial and boot values when loading GUCs

  3. Clean up some inconsistencies with GUC declarations

  4. Clean up some GUC declarations and comments