All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Hildenbrand <david@redhat.com>
To: yaozhenguo <yaozhenguo1@gmail.com>,
	mike.kravetz@oracle.com, corbet@lwn.net,
	akpm@linux-foundation.org
Cc: yaozhenguo@jd.com, willy@infradead.org,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	linux-mm@kvack.org
Subject: Re: [PATCH V1] hugetlbfs: Extend the definition of hugepages parameter to support node allocation
Date: Mon, 23 Aug 2021 21:17:20 +0200	[thread overview]
Message-ID: <be7017ea-0728-b342-0c78-f88256024dfb@redhat.com> (raw)
In-Reply-To: <20210823130154.75070-1-yaozhenguo1@gmail.com>

On 23.08.21 15:01, yaozhenguo 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, extend hugepages kernel parameter to specify
> node number of hugepages to allocate at boot.
> For example add following parameter:
> 
> hugepagesz=1G hugepages=0:1,1:3
> 
> It will allocate 1 hugepags in node0 and 3 hugepages in node1.

I like this format.


-- 
Thanks,

David / dhildenb


  reply	other threads:[~2021-08-23 19:17 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-23 13:01 [PATCH V1] hugetlbfs: Extend the definition of hugepages parameter to support node allocation yaozhenguo
2021-08-23 19:17 ` David Hildenbrand [this message]
2021-08-24  3:53 姚振国

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=be7017ea-0728-b342-0c78-f88256024dfb@redhat.com \
    --to=david@redhat.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=mike.kravetz@oracle.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.