Re: [PATCH] mm/hugetlb: avoid weird message in hugetlb_init

[Mike Kravetz <mike.kravetz@oracle.com>]

On 4/10/20 8:47 AM, Nitesh Narayan Lal wrote:
> Hi Mike,
> 
> On platforms that support multiple huge page sizes when 'hugepagesz' is not
> specified before 'hugepages=', hugepages are not allocated. (For example
> if we are requesting 1GB hugepages)

Hi Nitesh,

This should only be an issue with gigantic huge pages.  This is because
hugepages=X not following a hugepagesz=Y specifies the number of huge pages
of default size to allocate.  It does not currently work for gigantic pages.
In the other thread, I provided this explanation as to why:
It comes about because we do not definitively set the default huge page size
until after command line processing (in hugetlb_init).  And, we must
preallocate gigantic huge pages during command line processing because that
is when the bootmem allocater is available.

I will be looking into modifying this behavior to allocate the pages as
expected, even for gigantic pages.

> In terms of reporting meminfo and /sys/kernel/../nr_hugepages reports the
> expected results but if we use sysctl vm.nr_hugepages then it reports a non-zero
> value as it reads the max_huge_pages from the default hstate instead of
> nr_huge_pages.
> AFAIK nr_huge_pages is the one that indicates the number of huge pages that are
> successfully allocated.
> 
> Does vm.nr_hugepages is expected to report the maximum number of hugepages? If
> so, will it not make sense to rename the procname?
> 
> However, if we expect nr_hugepages to report the number of successfully
> allocated hugepages then we should use nr_huge_pages in
> hugetlb_sysctl_handler_common().

This looks like a bug.  Neither sysctl or the /proc file should be reporting
a non-zero value if huge pages do not exist.
-- 
Mike Kravetz