linux-kernel - [RFC PATCH v2 0/5] hugetlb: parallelize hugetlb page init on boot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20231208025240.4744-1-gang.li@linux.dev>
Date:   Fri,  8 Dec 2023 10:52:35 +0800
From:   Gang Li <gang.li@...ux.dev>
To:     David Hildenbrand <david@...hat.com>,
        David Rientjes <rientjes@...gle.com>,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Muchun Song <muchun.song@...ux.dev>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        ligang.bdlg@...edance.com, Gang Li <gang.li@...ux.dev>
Subject: [RFC PATCH v2 0/5] hugetlb: parallelize hugetlb page init on boot

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