Hello Christophe
On 24/01/25 19:44, Christophe Leroy wrote:
Le 24/01/2025 à 11:32, Sourabh Jain a écrit :
The fadump kernel boots with limited memory solely to collect the kernel
core dump. Having gigantic hugepages in the fadump kernel is of no use.
Many times, the fadump kernel encounters OOM (Out of Memory) issues if
gigantic hugepages are allocated.
To address this, disable gigantic hugepages if fadump is active by
returning early from arch_hugetlb_valid_size() using
hugepages_supported(). hugepages_supported() returns false if fadump is
active.
Returning early from arch_hugetlb_valid_size() not only disables
gigantic hugepages but also avoids unnecessary hstate initialization for
every hugepage size supported by the platform.
kernel logs related to hugepages with this patch included:
kernel argument passed: hugepagesz=1G hugepages=1
First kernel: gigantic hugepage got allocated
==============================================
dmesg | grep -i "hugetlb"
-------------------------
HugeTLB: registered 1.00 GiB page size, pre-allocated 1 pages
HugeTLB: 0 KiB vmemmap can be freed for a 1.00 GiB page
HugeTLB: registered 2.00 MiB page size, pre-allocated 0 pages
HugeTLB: 0 KiB vmemmap can be freed for a 2.00 MiB page
$ cat /proc/meminfo | grep -i "hugetlb"
-------------------------------------
Hugetlb: 1048576 kB
Fadump kernel: gigantic hugepage not allocated
===============================================
dmesg | grep -i "hugetlb"
-------------------------
[ 0.000000] HugeTLB: unsupported hugepagesz=1G
[ 0.000000] HugeTLB: hugepages=1 does not follow a valid
hugepagesz, ignoring
[ 0.706375] HugeTLB support is disabled!
[ 0.773530] hugetlbfs: disabling because there are no supported
hugepage sizes
$ cat /proc/meminfo | grep -i "hugetlb"
----------------------------------
<Nothing>
Cc: Hari Bathini <hbath...@linux.ibm.com>
Cc: Madhavan Srinivasan <ma...@linux.ibm.com>
Cc: Mahesh Salgaonkar <mah...@linux.ibm.com>
Cc: Michael Ellerman <m...@ellerman.id.au>
Cc: Ritesh Harjani (IBM)" <ritesh.l...@gmail.com>
Signed-off-by: Sourabh Jain <sourabhj...@linux.ibm.com>
---
Changelog:
v1:
https://lore.kernel.org/all/20250121150419.1342794-1-sourabhj...@linux.ibm.com/
v2:
- disable gigantic hugepage in arch code, arch_hugetlb_valid_size()
---
arch/powerpc/mm/hugetlbpage.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/mm/hugetlbpage.c
b/arch/powerpc/mm/hugetlbpage.c
index 6b043180220a..087a8df32416 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -135,8 +135,12 @@ int __init alloc_bootmem_huge_page(struct hstate
*h, int nid)
bool __init arch_hugetlb_valid_size(unsigned long size)
{
- int shift = __ffs(size);
- int mmu_psize;
+ int shift, mmu_psize;
+
+ if (!hugepages_supported())
+ return false;
+
+ shift = __ffs(size);
Why change the declaration/init of shift ?
I did this to avoid running code that wasn't necessary.
It should be enough to leave things as they are and just add
if (!hugepages_supported())
return false;
Sure.
/* Check that it is a page size supported by the hardware and
* that it fits within pagetable and slice limits. */
Thanks for the review.
- Sourabh Jain
