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
