From: Andrew Morton <akpm@linux-foundation.org>
To: yaozhenguo <yaozhenguo1@gmail.com>
Cc: mike.kravetz@oracle.com, corbet@lwn.net, yaozhenguo@jd.com,
willy@infradead.org, linux-kernel@vger.kernel.org,
linux-doc@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH v4] hugetlbfs: Extend the definition of hugepages parameter to support node allocation
Date: Tue, 14 Sep 2021 20:50:01 -0700 [thread overview]
Message-ID: <20210914205001.7ccc7ef3dd76a9ec551b370e@linux-foundation.org> (raw)
In-Reply-To: <20210909141655.87821-1-yaozhenguo1@gmail.com>
On Thu, 9 Sep 2021 22:16:55 +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 hugepages in one node. For example: DPDK needs hugepages
> which are in the same node as NIC. if DPDK needs four hugepages of 1G
> size in node1 and system has 16 numa nodes. We must reserve 64 hugepages
> in kernel cmdline. But, only four hugepages are used. The others should
> be free after boot. If the system memory is low(for example: 64G), it will
> be an impossible task. So, Extending hugepages parameter to support
> specifying hugepages at a specific node.
> For example add following parameter:
>
> hugepagesz=1G hugepages=0:1,1:3
>
> It will allocate 1 hugepage in node0 and 3 hugepages in node1.
>
> ...
>
> @@ -2842,10 +2843,75 @@ static void __init gather_bootmem_prealloc(void)
> }
> }
>
> +static void __init hugetlb_hstate_alloc_pages_onenode(struct hstate *h, int nid)
> +{
> + unsigned long i;
> + char buf[32];
> +
> + for (i = 0; i < h->max_huge_pages_node[nid]; ++i) {
> + if (hstate_is_gigantic(h)) {
> + struct huge_bootmem_page *m;
> + void *addr;
> +
> + addr = memblock_alloc_try_nid_raw(
> + huge_page_size(h), huge_page_size(h),
> + 0, MEMBLOCK_ALLOC_ACCESSIBLE, nid);
> + if (!addr)
> + break;
> + m = addr;
> + BUG_ON(!IS_ALIGNED(virt_to_phys(m), huge_page_size(h)));
We try very hard to avoid adding BUG calls. Is there any way in which
this code can emit a WARNing then permit the kernel to keep operating?
> + /*
> + * Put them into a private list first because mem_map
> + * is not up yet
> + */
> + INIT_LIST_HEAD(&m->list);
> + list_add(&m->list, &huge_boot_pages);
> + m->hstate = h;
> + } else {
> + struct page *page;
> +
> + gfp_t gfp_mask = htlb_alloc_mask(h) | __GFP_THISNODE;
> +
> + page = alloc_fresh_huge_page(h, gfp_mask, nid,
> + &node_states[N_MEMORY], NULL);
> + if (!page)
> + break;
> + put_page(page); /* free it into the hugepage allocator */
> + }
> + cond_resched();
> + }
> + if (i == h->max_huge_pages_node[nid])
> + return;
> +
> + string_get_size(huge_page_size(h), 1, STRING_UNITS_2, buf, 32);
> + pr_warn("HugeTLB: allocating %u of page size %s failed node%d. Only allocated %lu hugepages.\n",
> + h->max_huge_pages_node[nid], buf, nid, i);
> + h->max_huge_pages_node[nid] = i;
> + h->max_huge_pages -= (h->max_huge_pages_node[nid] - i);
> +}
> +
next prev parent reply other threads:[~2021-09-15 3:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-09 14:16 yaozhenguo
2021-09-15 3:50 ` Andrew Morton [this message]
2021-09-15 13:11 ` zhenguo yao
2021-09-15 22:03 ` Mike Kravetz
2021-09-15 22:05 ` Mike Kravetz
2021-09-17 13:59 ` Mike Rapoport
2021-09-15 22:38 ` Mike Kravetz
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=20210914205001.7ccc7ef3dd76a9ec551b370e@linux-foundation.org \
--to=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox