From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Shinoda, Noriyoshi (PN Japan FSIP) <noriyoshi.shinoda@hpe.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: pryzby@telsasoft.com <pryzby@telsasoft.com>
Cc: pgsql-hackers@postgresql.org <pgsql-hackers@postgresql.org>
Cc: rjuju123@gmail.com <rjuju123@gmail.com>
Cc: tgl@sss.pgh.pa.us <tgl@sss.pgh.pa.us>
Subject: Re: Improve logging when using Huge Pages
Date: Wed, 22 Sep 2021 02:03:11 +0900
Message-ID: <80872660-ad16-3040-0a25-bd741faa5fc0@oss.nttdata.com> (raw)
In-Reply-To: <TU4PR8401MB1152B1A4158D609472ABD51DEEA09@TU4PR8401MB1152.NAMPRD84.PROD.OUTLOOK.COM>
References: <20210907131653.GK26465@telsasoft.com>
<20210908.111736.355857044349579789.horikyota.ntt@gmail.com>
<7ad09915-d8b1-1bce-b962-7062e2cf346a@oss.nttdata.com>
<20210917.131430.1276120422145591578.horikyota.ntt@gmail.com>
<TU4PR8401MB1152B1A4158D609472ABD51DEEA09@TU4PR8401MB1152.NAMPRD84.PROD.OUTLOOK.COM>
On 2021/09/20 17:55, Shinoda, Noriyoshi (PN Japan FSIP) wrote:
> 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.
Probably I understood your point. But isn't it more confusing to users?
Because whether the log message is output or not is changed depending on
the setting of the kernel parameter. For example, when vm.nr_hugepages=0
and no log message about huge pages is output, users might easily misunderstand
that shared memory was successfully allocated with huge pages because
they saw no such log message.
IMO we should leave the log message "mmap(%zu) with MAP_HUGETLB failed..."
as it is if users don't like additional log message output whenever
the server restarts. In this case, instead, maybe it's better to provide GUC or
something to report whether shared memory was successfully allocated
with huge pages or not.
OTOH, if users can accept such additional log message, I think that it's
less confusing to report something like "disable huge pages ..." whenever
mmap() with huge pages fails. I still prefer "disable huge pages ..." to
"fall back ..." as the log message, but if many people think the latter is
better, I'd follow that.
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.
Regards,
--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: masao.fujii@oss.nttdata.com, noriyoshi.shinoda@hpe.com, horikyota.ntt@gmail.com, pryzby@telsasoft.com, rjuju123@gmail.com, tgl@sss.pgh.pa.us
Subject: Re: Improve logging when using Huge Pages
In-Reply-To: <80872660-ad16-3040-0a25-bd741faa5fc0@oss.nttdata.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox