Sourabh Jain <[email protected]> writes: > Skip processing hugepage kernel arguments (hugepagesz, hugepages, and > default_hugepagesz) when hugepages are not supported by the > architecture. > > Some architectures may need to disable hugepages based on conditions > discovered during kernel boot. The hugepages_supported() helper allows > architecture code to advertise whether hugepages are supported. > > Currently, normal hugepage allocation is guarded by > hugepages_supported(), but gigantic hugepages are allocated regardless > of this check. This causes problems on powerpc for fadump (firmware- > assisted dump). > > In the fadump (firmware-assisted dump) scenario, a production kernel > crash causes the system to boot into a special kernel whose sole > purpose is to collect the memory dump and reboot. Features such as > hugepages are not required in this environment and should be > disabled. > > For example, fadump kernel booting with the kernel arguments > default_hugepagesz=1GB hugepagesz=1GB hugepages=200 prints the > following logs: > > HugeTLB: allocating 200 of page size 1.00 GiB failed. Only allocated 58 > hugepages. > HugeTLB support is disabled! > HugeTLB: huge pages not supported, ignoring associated command-line parameters > hugetlbfs: disabling because there are no supported hugepage sizes > > Even though the logs say that hugetlb support is disabled, gigantic > hugepages are still getting allocated, which causes the fadump kernel > to run out of memory during boot. > > To fix this, the gigantic hugepage allocation should come under > hugepages_supported(). > > To bring gigantic hugepage allocation under hugepages_supported(), two > approaches were previously proposed: > [1] Check hugepages_supported() in the generic code before allocating > gigantic hugepages. > [2] Make arch_hugetlb_valid_size() return false for all hugetlb sizes. > > Approach [2] has two minor issues: > 1. It prints misleading logs about invalid hugepage sizes > 2. The kernel still processes hugepage kernel arguments unnecessarily >
And that every other architecture will have to duplicate this in their arch_hugetlb_valid_size() whenever they face the same problem. Instead like at other places, hugepages_supported() should also be checked in the following cmdlines setup functions. > To control gigantic hugepage allocation, it is proposed to skip > processing the hugepage kernel arguments (hugepagesz, hugepages, and > default_hugepagesz) when hugepages_support() returns false. > Right. Thanks for taking care of it. I guess after this patch [1] moves hugetlbpage_init_defaultsize() to mmu_early_init_devtree(), it's good to bring back these checks in the respective cmdline setup functions which was removed as part of commit [2] [1]: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2354ad252b66695be02f4acd18e37bf6264f0464 [2]: https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c2833a5bf75b3657c4dd20b3709c8c702754cb1f LGTM. Please feel free to add: Reviewed-by: Ritesh Harjani (IBM) <[email protected]>
