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

From Kyotaro Horiguchi
Subject Re: Improve logging when using Huge Pages
Date
Msg-id 20210909.143442.1420418137984948166.horikyota.ntt@gmail.com
Whole thread Raw
In response to RE: Improve logging when using Huge Pages  ("Shinoda, Noriyoshi (PN Japan FSIP)" <noriyoshi.shinoda@hpe.com>)
List pgsql-hackers
Thanks!

At Wed, 8 Sep 2021 07:52:35 +0000, "Shinoda, Noriyoshi (PN Japan FSIP)" <noriyoshi.shinoda@hpe.com> wrote in 
> Hello,
> 
> Thank you everyone for comments.
> I have attached a patch that simply changed the message like the advice from Horiguchi-san.
> 
> > Even with the patch, there are still some cases where huge pages is disabled silently. We should report something
evenin these cases?
 
> > For example, in the platform where huge pages is not supported, it's silently disabled when huge_pages=try.
> 
> The area where this patch is written is inside the "#ifdef MAP_HUGETLB #endif" block.
> For this reason, I think it is excluded from binaries created in an environment that does not have the MAP_HUGETLB
macro.

Ah, right.

> > One big concern about the patch is that log message is always reported when shared memory fails to be allocated
withhuge pages enabled when huge_pages=try. Since 
 
> > huge_pages=try is the default setting, many users would see this new log message whenever they start the server.
Thosewho don't need huge pages but just use the default 
 
> > setting might think that such log messages would be noisy.
> 
> This patch is meant to let the admin know that HugePages isn't being used, so I'm sure you're right. I have no idea
whatto do so far.
 

It seems *to me* sufficient. I'm not sure what cases CreateFileMapping
return ERROR_NO_SYSTEM_RESOURCES when non-huge page can be allocated
successfully, though, but that doesn't matter much, maybe.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: strange case of "if ((a & b))"
Next
From: Pavel Stehule
Date:
Subject: Re: [PROPOSAL] new diagnostic items for the dynamic sql