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
