From: Baolin Wang <baolin.wang@linux.alibaba.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: mike.kravetz@oracle.com, mhocko@kernel.org, guro@fb.com,
corbet@lwn.net, yaozhenguo1@gmail.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org
Subject: Re: [PATCH] hugetlb: Support node specified when using cma for gigantic hugepages
Date: Mon, 11 Oct 2021 10:14:01 +0800 [thread overview]
Message-ID: <d0d09382-c6ea-bf60-efbd-11a57a09263d@linux.alibaba.com> (raw)
In-Reply-To: <20211010135507.f2d1c6bcaeecc82d6d025604@linux-foundation.org>
On 2021/10/11 4:55, Andrew Morton wrote:
> On Sun, 10 Oct 2021 13:24:08 +0800 Baolin Wang <baolin.wang@linux.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?
Sure. On some multi-nodes systems, each node's memory can be different,
allocating the same size of CMA for each node is not suitable for the
low-memory nodes. Meanwhile some workloads like DPDK mentioned by
Zhenguo only need hugepages in one node.
On the other hand, we have some machines with multiple types of memory,
like DRAM and PMEM (persistent memory). On this system, we may want to
specify all the hugepages on DRAM node, or specify the proportion of
DRAM node and PMEM node, to tuning the performance of the workloads.
next prev parent reply other threads:[~2021-10-11 2:13 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-10 5:24 Baolin Wang
2021-10-10 20:55 ` Andrew Morton
2021-10-11 2:14 ` Baolin Wang [this message]
2021-10-13 22:06 ` Mike Kravetz
2021-10-14 2:23 ` Baolin Wang
2021-10-14 2:30 ` Mike Kravetz
2021-10-14 2:39 ` Baolin Wang
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=d0d09382-c6ea-bf60-efbd-11a57a09263d@linux.alibaba.com \
--to=baolin.wang@linux.alibaba.com \
--cc=akpm@linux-foundation.org \
--cc=corbet@lwn.net \
--cc=guro@fb.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@kernel.org \
--cc=mike.kravetz@oracle.com \
--cc=yaozhenguo1@gmail.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