From: Gang Li <gang.li@linux.dev>
To: David Hildenbrand <david@redhat.com>,
David Rientjes <rientjes@google.com>,
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,
ligang.bdlg@bytedance.com, Gang Li <gang.li@linux.dev>
Subject: [RFC PATCH v2 0/5] hugetlb: parallelize hugetlb page init on boot
Date: Fri, 8 Dec 2023 10:52:35 +0800 [thread overview]
Message-ID: <20231208025240.4744-1-gang.li@linux.dev> (raw)
Hi all, hugetlb init parallelization has now been updated to v2.
To David Hildenbrand: padata multithread utilities has been used to reduce
code complexity.
To David Rientjes: The patch for measuring time will be separately included
in the reply. Please test during your free time, thanks.
# Introduction
Hugetlb initialization during boot takes up a considerable amount of time.
For instance, on a 2TB system, initializing 1,800 1GB huge pages takes 1-2
seconds out of 10 seconds. Initializing 11,776 1GB pages on a 12TB Intel
host takes 65.2 seconds [1], which is 17.4% of the total 373.78 seconds boot
time. This is a noteworthy figure.
Inspired by [2] and [3], hugetlb initialization can also be accelerated
through parallelization. Kernel already has infrastructure like
padata_do_multithreaded, this patch uses it to achieve effective results
by minimal modifications.
[1] https://lore.kernel.org/all/783f8bac-55b8-5b95-eb6a-11a583675000@google.com/
[2] https://lore.kernel.org/all/20200527173608.2885243-1-daniel.m.jordan@oracle.com/
[3] https://lore.kernel.org/all/20230906112605.2286994-1-usama.arif@bytedance.com/
# Test result
test no patch(ms) patched(ms) saved
------------------- -------------- ------------- --------
256c2t(4 node) 2M 2624 956 63.57%
256c2t(4 node) 1G 2679 1582 40.95%
128c1t(2 node) 2M 1788 684 61.74%
128c1t(2 node) 1G 3160 1618 48.80%
# Change log
Changes in v2:
- Reduce complexity with `padata_do_multithreaded`
- Support 1G hugetlb
v1:
- https://lore.kernel.org/all/20231123133036.68540-1-gang.li@linux.dev/
- parallelize 2M hugetlb initialization with workqueue
Gang Li (5):
hugetlb: code clean for hugetlb_hstate_alloc_pages
hugetlb: split hugetlb_hstate_alloc_pages
padata: dispatch works on different nodes
hugetlb: parallelize 2M hugetlb allocation and initialization
hugetlb: parallelize 1G hugetlb initialization
include/linux/hugetlb.h | 2 +-
include/linux/padata.h | 2 +
kernel/padata.c | 8 +-
mm/hugetlb.c | 201 +++++++++++++++++++++++++++-------------
mm/mm_init.c | 1 +
5 files changed, 148 insertions(+), 66 deletions(-)
--
2.30.2
next reply other threads:[~2023-12-08 2:53 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-08 2:52 Gang Li [this message]
2023-12-08 2:52 ` [RFC PATCH v2 1/5] hugetlb: code clean for hugetlb_hstate_alloc_pages Gang Li
2023-12-08 2:52 ` [RFC PATCH v2 2/5] hugetlb: split hugetlb_hstate_alloc_pages Gang Li
2023-12-08 2:52 ` [RFC PATCH v2 3/5] padata: dispatch works on different nodes Gang Li
2023-12-12 23:40 ` Tim Chen
2023-12-18 6:46 ` Gang Li
2023-12-27 10:33 ` Gang Li
2023-12-08 2:52 ` [RFC PATCH v2 4/5] hugetlb: parallelize 2M hugetlb allocation and initialization Gang Li
2023-12-08 2:52 ` [RFC PATCH v2 5/5] hugetlb: parallelize 1G hugetlb initialization Gang Li
2023-12-08 2:56 ` [PATCH 1/1] hugetlb: add timing to hugetlb allocations on boot Gang Li
2023-12-12 20:06 ` [RFC PATCH v2 0/5] hugetlb: parallelize hugetlb page init " Mike Kravetz
2023-12-21 7:22 ` Gang Li
2023-12-12 22:14 ` David Rientjes
2023-12-12 23:08 ` Mike Kravetz
2023-12-13 0:10 ` David Rientjes
2023-12-18 6:34 ` Gang Li
2023-12-22 4:33 ` David Rientjes
2023-12-25 5:21 ` David Rientjes
2023-12-25 6:24 ` Gang Li
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=20231208025240.4744-1-gang.li@linux.dev \
--to=gang.li@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=ligang.bdlg@bytedance.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=muchun.song@linux.dev \
--cc=rientjes@google.com \
/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