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