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; 4+ 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] 4+ messages in thread

* RE:  Re: [PATCH] mm/hugetlb: two-phase hugepage allocation when reservation is high
@ 2025-08-27  4:12 Li,Rongqing
  2025-08-27 11:51 ` David Hildenbrand
  0 siblings, 1 reply; 4+ 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] 4+ messages in thread

* Re: [PATCH] mm/hugetlb: two-phase hugepage allocation when reservation is high
  2025-08-27  4:12 Re: [PATCH] mm/hugetlb: two-phase hugepage allocation when reservation is high Li,Rongqing
@ 2025-08-27 11:51 ` David Hildenbrand
  0 siblings, 0 replies; 4+ messages in thread
From: David Hildenbrand @ 2025-08-27 11:51 UTC (permalink / raw)
  To: Li,Rongqing, 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)

On 27.08.25 06:12, Li,Rongqing wrote:
> 
> .
>>
>> 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));

I don't like hard coding that here.

> +
> +               job.start       = h->nr_huge_pages;
> +               job.size        = remaining;
> +               job.min_chunk   = remaining / hugepage_allocation_threads;
> +               padata_do_multithreaded(&job);
> +       }

Thinking out load, can't we try in a loop until either

a) We allocated all we need

b) We don't make any more progress


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;
+
+               /* 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 related	[flat|nested] 4+ 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; 4+ 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] 4+ messages in thread

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

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-08-27  4:12 Re: [PATCH] mm/hugetlb: two-phase hugepage allocation when reservation is high Li,Rongqing
2025-08-27 11:51 ` David Hildenbrand
  -- strict thread matches above, loose matches on Subject: below --
2025-08-27 12:33 Li,Rongqing
2025-08-25  2:27 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).