From: lirongqing <lirongqing@baidu.com>
To: <muchun.song@linux.dev>, <osalvador@suse.de>, <david@redhat.com>,
<akpm@linux-foundation.org>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>,
<giorgitchankvetadze1997@gmail.com>
Cc: Li RongQing <lirongqing@baidu.com>
Subject: [PATCH][v3] mm/hugetlb: Retry to allocate for early boot hugepage allocation
Date: Fri, 29 Aug 2025 17:52:41 +0800 [thread overview]
Message-ID: <20250829095241.2651-1-lirongqing@baidu.com> (raw)
From: Li RongQing <lirongqing@baidu.com>
In cloud environments with massive hugepage reservations (95%+ of system
RAM), single-attempt allocation during early boot often fails due to
memory pressure.
Commit 91f386bf0772 ("hugetlb: batch freeing of vmemmap pages") intensified
this by deferring page frees, increase peak memory usage during allocation.
Introduce a retry mechanism that leverages vmemmap optimization reclaim
(~1.6% memory) when available. Upon initial allocation failure, the system
retries until successful or no further progress is made, ensuring reliable
hugepage allocation while preserving batched vmemmap freeing benefits.
Testing on a 256G machine allocating 252G of hugepages:
Before: 128056/129024 hugepages allocated
After: Successfully allocated all 129024 hugepages
Suggested-by: David Hildenbrand <david@redhat.com>
Signed-off-by: Li RongQing <lirongqing@baidu.com>
---
Diff with v2: auto retry mechanism
Diff with v1: add log if two-phase hugepage allocation is triggered
add the knod to control split ratio
mm/hugetlb.c | 27 +++++++++++++++++++++++----
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 753f99b..18e54ea 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3589,10 +3589,9 @@ static unsigned long __init hugetlb_pages_alloc_boot(struct hstate *h)
unsigned long jiffies_start;
unsigned long jiffies_end;
+ unsigned long remaining;
job.thread_fn = hugetlb_pages_alloc_boot_node;
- job.start = 0;
- job.size = h->max_huge_pages;
/*
* job.max_threads is 25% of the available cpu threads by default.
@@ -3616,10 +3615,30 @@ static unsigned long __init hugetlb_pages_alloc_boot(struct hstate *h)
}
job.max_threads = hugepage_allocation_threads;
- job.min_chunk = h->max_huge_pages / hugepage_allocation_threads;
jiffies_start = jiffies;
- padata_do_multithreaded(&job);
+ do {
+ remaining = h->max_huge_pages - h->nr_huge_pages;
+
+ job.start = h->nr_huge_pages;
+ job.size = remaining;
+ job.min_chunk = remaining / hugepage_allocation_threads;
+ padata_do_multithreaded(&job);
+
+ if (h->nr_huge_pages == h->max_huge_pages)
+ break;
+
+ /*
+ * Retry allocation if vmemmap optimization is available, the
+ * optimization frees ~1.6% of memory of hugepages, this reclaimed
+ * memory enables additional hugepage allocations
+ */
+ if (!hugetlb_vmemmap_optimizable(h))
+ break;
+
+ /* Continue if progress was made in last iteration */
+ } while (remaining != (h->max_huge_pages - h->nr_huge_pages));
+
jiffies_end = jiffies;
pr_info("HugeTLB: allocation took %dms with hugepage_allocation_threads=%ld\n",
--
2.9.4
next reply other threads:[~2025-08-29 9:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-29 9:52 lirongqing [this message]
2025-08-29 15:03 ` David Hildenbrand
2025-08-29 15:20 Li,Rongqing
2025-08-29 19:20 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250829095241.2651-1-lirongqing@baidu.com \
--to=lirongqing@baidu.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=giorgitchankvetadze1997@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox