RE: Improve logging when using Huge Pages - Mailing list pgsql-hackers

From Shinoda, Noriyoshi (PN Japan FSIP)
Subject RE: Improve logging when using Huge Pages
Date
Msg-id TU4PR8401MB11529A0C57CEDCCBC39050EDEEA79@TU4PR8401MB1152.NAMPRD84.PROD.OUTLOOK.COM
Whole thread Raw
In response to Re: Improve logging when using Huge Pages  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: Improve logging when using Huge Pages
List pgsql-hackers
Hi, all.
Thank you for your comment.

> Probably I understood your point. But isn't it more confusing to users?
As you say, I think the last patch was rather confusing. For this reason, I simply reconsidered it.
The attached patch just outputs a log like your advice on acquiring Huge Page.
It is possible to limit the log output trigger only when huge_pages=try, but is it better not to always output it?

Regards,
Noriyoshi Shinoda

-----Original Message-----
From: Kyotaro Horiguchi [mailto:horikyota.ntt@gmail.com]
Sent: Monday, September 27, 2021 11:40 AM
To: pryzby@telsasoft.com
Cc: masao.fujii@oss.nttdata.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 Tue, 21 Sep 2021 19:23:22 -0500, Justin Pryzby <pryzby@telsasoft.com> wrote in
> On Wed, Sep 22, 2021 at 02:03:11AM +0900, Fujii Masao wrote:
> > Another idea is to output "Anonymous shared memory was allocated
> > with  huge pages" when it's successfully allocated with huge pages,
> > and to output  "Anonymous shared memory was allocated without huge pages"
> >  when it's successfully allocated without huge pages. I'm not sure
> > if users  may think even this message is noisy, though.
>
> +1

+1. Positive phrase looks better.

> Maybe it could show the page size instead of "with"/without:
> "Shared memory allocated with 4k/1MB/1GB pages."

+1.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

Attachment

pgsql-hackers by date:

Previous
From: tushar
Date:
Subject: Re: extensible options syntax for replication parser?
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Corruption during WAL replay