linux-kernel - Re: [PATCH] hugetlb: Support node specified when using cma for gigantic hugepages

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sun, 10 Oct 2021 13:55:07 -0700
From:   Andrew Morton <akpm@...ux-foundation.org>
To:     Baolin Wang <baolin.wang@...ux.alibaba.com>
Cc:     mike.kravetz@...cle.com, mhocko@...nel.org, guro@...com,
        corbet@....net, yaozhenguo1@...il.com, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, linux-doc@...r.kernel.org
Subject: Re: [PATCH] hugetlb: Support node specified when using cma for
 gigantic hugepages

On Sun, 10 Oct 2021 13:24:08 +0800 Baolin Wang <baolin.wang@...ux.alibaba.com> wrote:

> Now the size of CMA area for gigantic hugepages runtime allocation is
> balanced for all online nodes, but we also want to specify the size of
> CMA per-node, or only one node in some cases, which are similar with

Please describe in full detail why "we want to" do this.  In other
words, what is the benefit to our users?  What are the use-cases, etc?

> commit 86acc55c3d32 ("hugetlbfs: extend the definition of hugepages
> parameter to support node allocation")[1].
> 
> Thus this patch adds node format for 'hugetlb_cma' parameter to support
> specifying the size of CMA per-node. An example is as follows:
> 
> hugetlb_cma=0:5G,2:5G
> 
> which means allocating 5G size of CMA area on node 0 and node 2
> respectively.
>