Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::3:5 as permitted sender) client-ip=2620:137:e000::3:5;
From:   Gang Li <gang.li@linux.dev>
To:     Mike Kravetz <mike.kravetz@oracle.com>,
        Muchun Song <muchun.song@linux.dev>,
        Andrew Morton <akpm@linux-foundation.org>
Cc:     linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        Gang Li <ligang.bdlg@bytedance.com>
Subject: [RFC PATCH v1 0/4] hugetlb: parallelize hugetlb page allocation on boot
Date:   Thu, 23 Nov 2023 21:30:32 +0800
Message-Id: <20231123133036.68540-1-gang.li@linux.dev>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Precedence: bulk

From: Gang Li <ligang.bdlg@bytedance.com>

Inspired by these patches [1][2], this series aims to speed up the
initialization of hugetlb during the boot process through
parallelization.

It is particularly effective in large systems. On a machine equipped
with 1TB of memory and two NUMA nodes, the time for hugetlb
initialization was reduced from 2 seconds to 1 second.

In the future, as memory continues to grow, more and more time can
be saved.

This series currently focuses on optimizing 2MB hugetlb. Since
gigantic pages are few in number, their optimization effects
are not as pronounced. We may explore optimizations for
gigantic pages in the future.

Thanks,
Gang Li

Gang Li (4):
  hugetlb: code clean for hugetlb_hstate_alloc_pages
  hugetlb: split hugetlb_hstate_alloc_pages
  hugetlb: add timing to hugetlb allocations on boot
  hugetlb: parallelize hugetlb page allocation

 mm/hugetlb.c | 191 ++++++++++++++++++++++++++++++++++++---------------
 1 file changed, 134 insertions(+), 57 deletions(-)

-- 
2.20.1