RE: Re: [PATCH] mm/hugetlb: two-phase hugepage allocation when reservation is high

["Li,Rongqing" <lirongqing@baidu.com>]

.
> 
> 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