linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* RE:  Re: [PATCH] mm/hugetlb: two-phase hugepage allocation when reservation is high
@ 2025-08-25  2:27 Li,Rongqing
  0 siblings, 0 replies; 3+ messages in thread
From: Li,Rongqing @ 2025-08-25  2:27 UTC (permalink / raw)
  To: Giorgi Tchankvetadze
  Cc: akpm@linux-foundation.org, david@redhat.com,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	muchun.song@linux.dev, osalvador@suse.de, Xu,Wenjie(ACG CCN)

> 
> Hi there. The 90% split is solid. Would it make sense to (a) log a one-time
> warning if the second pass is triggered, so operators know why boot slowed,

Ok

> and (b) make the 90% cap a Kconfig default ratio, so distros can lower it
> without patching? Both are low-risk and don’t change the ABI
>

I think it is better to add a cmdline option

-Li



^ permalink raw reply	[flat|nested] 3+ messages in thread

* RE:  Re: [PATCH] mm/hugetlb: two-phase hugepage allocation when reservation is high
@ 2025-08-27  4:12 Li,Rongqing
  0 siblings, 0 replies; 3+ messages in thread
From: Li,Rongqing @ 2025-08-27  4:12 UTC (permalink / raw)
  To: David Hildenbrand, muchun.song@linux.dev, osalvador@suse.de,
	akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, giorgitchankvetadze1997@gmail.com
  Cc: Xu,Wenjie(ACG CCN)


.
> 
> Also, can't we fail lightly during the first attempt and dynamically decide if we
> should do a second pase?
> 


Good idea, like below

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 753f99b..425a759 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3589,6 +3589,7 @@ 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;
@@ -3620,6 +3621,18 @@ static unsigned long __init hugetlb_pages_alloc_boot(struct hstate *h)

        jiffies_start = jiffies;
        padata_do_multithreaded(&job);
+
+       if (h->nr_huge_pages != h->max_huge_pages && hugetlb_vmemmap_optimizable(h)) {
+               remaining = h->max_huge_pages - h->nr_huge_pages;
+               /* vmemmap optimization can save about 1.6% (4/250) memory */
+               remaining = min(remaining, (h->nr_huge_pages * 4 / 250));
+
+               job.start       = h->nr_huge_pages;
+               job.size        = remaining;
+               job.min_chunk   = remaining / hugepage_allocation_threads;
+               padata_do_multithreaded(&job);
+       }

Thanks

-Li

> --
> Cheers
> 
> David / dhildenb


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* RE: Re: [PATCH] mm/hugetlb: two-phase hugepage allocation when reservation is high
@ 2025-08-27 12:33 Li,Rongqing
  0 siblings, 0 replies; 3+ messages in thread
From: Li,Rongqing @ 2025-08-27 12:33 UTC (permalink / raw)
  To: David Hildenbrand, muchun.song@linux.dev, osalvador@suse.de,
	akpm@linux-foundation.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, giorgitchankvetadze1997@gmail.com
  Cc: Xu,Wenjie(ACG CCN)

> Not sure if something like the following could fly:
> 
> diff --git a/mm/hugetlb.c b/mm/hugetlb.c index
> 1f42186a85ea4..dfb4d717b8a02 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c
> @@ -3595,8 +3595,6 @@ static unsigned long __init
> hugetlb_pages_alloc_boot(struct hstate *h)
>          unsigned long jiffies_end;
> 
>          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.
> @@ -3620,10 +3618,24 @@ 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);
> +       /* TODO: comment why we retry and how it interacts with
> vmemmap op. */
> +       while (h->nr_huge_pages != h->max_huge_pages) {
> +               unsigned long 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 (hugetlb_vmemmap_optimizable(h))
> +                       break;

It should be:
           if (!hugetlb_vmemmap_optimizable(h))
                     break;

other is fine to me

thanks

-Li


> +
> +               /* Stop if there is no progress. */
> +               if (remaining == h->max_huge_pages - h->nr_huge_pages)
> +                       break;
> +       }
>          jiffies_end = jiffies;
> 
>          pr_info("HugeTLB: allocation took %dms with
> hugepage_allocation_threads=%ld\n",
> 
> 
> --
> Cheers
> 
> David / dhildenb


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2025-08-27 12:33 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-08-25  2:27 Re: [PATCH] mm/hugetlb: two-phase hugepage allocation when reservation is high Li,Rongqing
  -- strict thread matches above, loose matches on Subject: below --
2025-08-27  4:12 Li,Rongqing
2025-08-27 12:33 Li,Rongqing

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).