linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mike Kravetz <mike.kravetz@oracle.com>
To: Matthew Wilcox <willy@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>
Cc: yaozhenguo <yaozhenguo1@gmail.com>,
	corbet@lwn.net, yaozhenguo@jd.com, linux-kernel@vger.kernel.org,
	linux-doc@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH] hugetlbfs: add hugepages_node kernel parameter
Date: Mon, 23 Aug 2021 09:52:43 -0700	[thread overview]
Message-ID: <440095e1-a564-d522-eb86-1eaaa0dbf572@oracle.com> (raw)
In-Reply-To: <YSLPWybBCyE/6x7s@casper.infradead.org>

On 8/22/21 3:27 PM, Matthew Wilcox wrote:
> On Sun, Aug 22, 2021 at 03:19:52PM -0700, Andrew Morton wrote:
>> On Fri, 20 Aug 2021 11:05:36 +0800 yaozhenguo <yaozhenguo1@gmail.com> wrote:
>>
>>> We can specify the number of hugepages to allocate at boot. But the
>>> hugepages is balanced in all nodes at present. In some scenarios,
>>> we only need hugepags in one node. For example: DPDK needs hugepages
>>> which is in the same node as NIC. if DPDK needs four hugepags of 1G
>>> size in node1 and system has 16 numa nodes. We must reserve 64 hugepags
>>> in kernel cmdline. But, only four hugepages is used. The others should
>>> be free after boot.If the system memory is low(for example: 64G), it will
>>> be an impossible task. So, add hugepages_node kernel parameter to specify
>>> node number of hugepages to allocate at boot.
>>> For example add following parameter:
>>>
>>> hugepagesz=1G hugepages_node=1 hugepages=4
>>>
>>> It will allocate 4 hugepags in node1 at boot.
>>
>> If were going to do this, shouldn't we permit more than one node?
>>
>> 	hugepages_nodes=1,2,5
> 
> I'd think we'd be better off expanding the definition of hugepages.
> eg:
> 
> hugepagesz=1G hugepages=1:4,3:8,5:2
> 
> would say to allocate 4 pages from node 1, 8 pages from node 3 and 2
> pages from node 5.

Thanks Matthew and Andrew!

I was trying to wrap my head around the big issue before making any
suggestions.  It is true that the desired functionality of allocating
huge pages from a specific node is lacking today.

I like the idea of expanding the definition of hugepages so that nodes
can be specified.

One word of caution.  It is easy to make mistakes when taking data
directly from the user on the command line.  For example, in the follow
on patch I do not believe node is not checked against MAX_NUMNODES so
it may write beyond the end of array.  Also, we need to think about what
the behavior should be if part of the
'node1:count1,node2:count2,node3:count3' string is invalid?  Suppose
node2 is invalid.  Do we still allocate from node1 and node3, or do we
just discard the entire string?  During a recent rewrite of hugetlb
command line processing, I had a matrix of different command line
options, order, values and expected results.  We need to be as thorough
when adding this new option.

I'll take a closer look at the proposed patch in the next few days.
-- 
Mike Kravetz

  parent reply	other threads:[~2021-08-23 16:53 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-20  3:05 [PATCH] hugetlbfs: add hugepages_node kernel parameter yaozhenguo
2021-08-22 22:19 ` Andrew Morton
2021-08-22 22:27   ` Matthew Wilcox
2021-08-23  1:57     ` zhenguo yao
2021-08-23 16:52     ` Mike Kravetz [this message]
2021-08-23  2:04   ` zhenguo yao

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=440095e1-a564-d522-eb86-1eaaa0dbf572@oracle.com \
    --to=mike.kravetz@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=corbet@lwn.net \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=willy@infradead.org \
    --cc=yaozhenguo1@gmail.com \
    --cc=yaozhenguo@jd.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).