From: Mike Kravetz <mike.kravetz@oracle.com>
To: Gang Li <gang.li@linux.dev>
Cc: David Hildenbrand <david@redhat.com>,
David Rientjes <rientjes@google.com>,
Muchun Song <muchun.song@linux.dev>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
ligang.bdlg@bytedance.com
Subject: Re: [RFC PATCH v2 0/5] hugetlb: parallelize hugetlb page init on boot
Date: Tue, 12 Dec 2023 12:06:53 -0800 [thread overview]
Message-ID: <20231212200653.GA7043@monkey> (raw)
In-Reply-To: <20231208025240.4744-1-gang.li@linux.dev>
On 12/08/23 10:52, Gang Li wrote:
> Hi all, hugetlb init parallelization has now been updated to v2.
Thanks for your efforts, and sorry for my late comments.
> 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.
One issue to be concerned with is hugetlb page allocation on systems with
unbalanced numa node memory. Commit f60858f9d327 ("hugetlbfs: don't retry
when pool page allocations start to fail") was added to deal with issues
reported on such systems. So, users are certainly using hugetlb pages
on systems with imbalances.
If performing allocations in parallel, I believe we would want the total
number of hugetlb pages allocated to be the same as today. For example,
consider a simple 2 node system with 16GB total memory:
node 0: 2GB
node 1: 14GB
With today's code, allocating 6656 2MB pages via the kernel command line
results in:
node 0: 924 pages
node 1: 5732 pages
total: 6656 pages
With code to parallel allocations in this series:
node 0: 924 pages
node 1: 1547 pages
total: 2471 pages
--
Mike Kravetz
next prev parent reply other threads:[~2023-12-12 20:07 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-08 2:52 [RFC PATCH v2 0/5] hugetlb: parallelize hugetlb page init on boot Gang Li
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 ` Mike Kravetz [this message]
2023-12-21 7:22 ` [RFC PATCH v2 0/5] hugetlb: parallelize hugetlb page init " 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=20231212200653.GA7043@monkey \
--to=mike.kravetz@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=gang.li@linux.dev \
--cc=ligang.bdlg@bytedance.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--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;
as well as URLs for NNTP newsgroup(s).