linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Li,Rongqing" <lirongqing@baidu.com>
To: David Hildenbrand <david@redhat.com>,
	"muchun.song@linux.dev" <muchun.song@linux.dev>,
	"osalvador@suse.de" <osalvador@suse.de>,
	"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
	"linux-mm@kvack.org" <linux-mm@kvack.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"giorgitchankvetadze1997@gmail.com"
	<giorgitchankvetadze1997@gmail.com>
Subject: RE:  Re: [PATCH][v3] mm/hugetlb: Retry to allocate for early boot hugepage allocation
Date: Fri, 29 Aug 2025 15:20:47 +0000	[thread overview]
Message-ID: <8c6e91ecb80c4707a52c253481cba51c@baidu.com> (raw)



> On 29.08.25 11:52, lirongqing wrote:
> > 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;

If all pages are allocated, it will break out from here. Since in most cases the first allocation is successful, I have moved this check to the very beginning.

> > +
> > +		/*
> > +		 * Retry allocation if vmemmap optimization is available, the
> > +		 * optimization frees ~1.6% of memory of hugepages, this reclaimed
> > +		 * memory enables additional hugepage allocations
> 
> As I said, please remove any calculation details about the vmemmap.
> That's not the place to have such calculations easily become stale.
> 
> Something like the following:
> 
> /*
>   * Retry only if the vmemmap optimization might have been able to free
>   * some memory back to the system.
>   */
> 

Thanks, I will fix it

> > +		 */
> > +		if (!hugetlb_vmemmap_optimizable(h))
> > +			break;
> > +
> > +	/* Continue if progress was made in last iteration */
> 
> Comment wrongly indented.
> 

checkpatch did not report error, I will fix it 

> > +	} while (remaining != (h->max_huge_pages - h->nr_huge_pages));
> 
> Why would you want to retry if you allocated all pages (IOW the common
> case)?
> 

See the reply before "if (h->nr_huge_pages == h->max_huge_pages)"

Thanks


> E.g.,
> 
> remaining == 1
> h->max_huge_pages == 1
> h->nr_huge_pages == 1
> 
> while (1 != 1 -1) -> while (1 != 0)
> 
> 
> you should probably do
> 
> do {
> 	...
> 
> 	/* Stop if there is no progress */
> 	if (remaining == h->max_huge_pages - h->nr_huge_pages)
> 		break;
> } (h->max_huge_pages != h->nr_huge_pages);
> 
> --
> Cheers
> 
> David / dhildenb


             reply	other threads:[~2025-08-29 15:21 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-08-29 15:20 Li,Rongqing [this message]
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=8c6e91ecb80c4707a52c253481cba51c@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