RE: Improve logging when using Huge Pages

From: "Shinoda, Noriyoshi (PN Japan FSIP)" <noriyoshi(dot)shinoda(at)hpe(dot)com>
To: "masao(dot)fujii(at)oss(dot)nttdata(dot)com" <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, "Kyotaro Horiguchi" <horikyota(dot)ntt(at)gmail(dot)com>
Cc: "pryzby(at)telsasoft(dot)com" <pryzby(at)telsasoft(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "rjuju123(at)gmail(dot)com" <rjuju123(at)gmail(dot)com>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: RE: Improve logging when using Huge Pages
Date: 2021-09-20 08:55:13
Message-ID: TU4PR8401MB1152B1A4158D609472ABD51DEEA09@TU4PR8401MB1152.NAMPRD84.PROD.OUTLOOK.COM
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(dot)ntt(at)gmail(dot)com]
Sent: Friday, September 17, 2021 1:15 PM
To: masao(dot)fujii(at)oss(dot)nttdata(dot)com
Cc: pryzby(at)telsasoft(dot)com; Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi(dot)shinoda(at)hpe(dot)com>; pgsql-hackers(at)postgresql(dot)org; rjuju123(at)gmail(dot)com; tgl(at)sss(dot)pgh(dot)pa(dot)us
Subject: Re: Improve logging when using Huge Pages

At Fri, 17 Sep 2021 00:13:41 +0900, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)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

Attachment Content-Type Size
huge_pages_log_v5.diff application/octet-stream 2.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Daniel Gustafsson 2021-09-20 09:38:16 Re: Support for NSS as a libpq TLS backend
Previous Message Pavel Luzanov 2021-09-20 08:47:02 Re: psql: \dl+ to list large objects privileges