On 4/15/20 12:03 AM, Mike Kravetz wrote: > On 4/13/20 2:21 PM, Nitesh Narayan Lal wrote: >> On 4/13/20 2:33 PM, Mike Kravetz wrote: >>> 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. >> I see, since we changed the default hugepages to gigantic pages and we missed >> 'hugepagesz=' no page were allocated of any type. >> >>> 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. >> Nice, looking forward to it. >> >>>> 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. >> Yeap, as I mentioned it reports max_huge_pages instead of the nr_huge_pages. > Does this only happen when you specify gigantic pages as the default huge > page size and they are not allocated at boot time? Yes. > Or, are there other > situations where this happens? If so, can you provide a sample of the > boot parameters used, or how to recreate. To reproduce this behavior boot the kernel with 'default_hugepagesz=1G hugepages=8' parameter in the kernel cmdline, hugepagesz needs to be skipped to ensure that no gigantic hugepages are allocated. After the kernel is up check the output of 'sysctl vm.nr_hugepages'. This should be good enough to reproduce this issue. > > I am fixing up the issue with gigantic pages, and suspect this will take > are of all the issues you are seeing. This will be part of the command line > cleanup series. Just want to make sure I am not missing something. Makes sense. Thank you. -- Nitesh
Attachment:
signature.asc
Description: OpenPGP digital signature