mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: David Rientjes <rientjes@google.com>
To: Gang Li <gang.li@linux.dev>
Cc: David Hildenbrand <david@redhat.com>,
	Mike Kravetz <mike.kravetz@oracle.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 14:14:49 -0800 (PST)	[thread overview]
Message-ID: <996ba32c-78f0-1807-5e64-af5841a820e7@google.com> (raw)
In-Reply-To: <20231208025240.4744-1-gang.li@linux.dev>

On Fri, 8 Dec 2023, Gang Li wrote:

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

I'd love to, but what kernel is this based on?  :)  I can't get this to 
apply to any kernels that I have recently benchmarked with.

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

  parent reply	other threads:[~2023-12-12 22:14 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-08  2:52 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 ` [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 [this message]
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=996ba32c-78f0-1807-5e64-af5841a820e7@google.com \
    --to=rientjes@google.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=mike.kravetz@oracle.com \
    --cc=muchun.song@linux.dev \
    /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

all inboxes | Powered by JetHome®