From: "liupeng (DM)" <liupeng256@huawei.com>
To: David Hildenbrand <david@redhat.com>, <mike.kravetz@oracle.com>,
<akpm@linux-foundation.org>, <yaozhenguo1@gmail.com>,
<linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
<stable@vger.kernel.org>
Subject: Re: [PATCH v2 1/2] hugetlb: Fix hugepages_setup when deal with pernode
Date: Sat, 2 Apr 2022 10:36:58 +0800 [thread overview]
Message-ID: <6900c697-2eaa-9e91-4d37-7a11c71d021f@huawei.com> (raw)
In-Reply-To: <0aefbc18-4232-0bae-b37a-d4c6995e3d00@redhat.com>
On 2022/4/1 18:43, David Hildenbrand wrote:
> On 01.04.22 12:12, Peng Liu wrote:
>> Hugepages can be specified to pernode since "hugetlbfs: extend
>> the definition of hugepages parameter to support node allocation",
>> but the following problem is observed.
>>
>> Confusing behavior is observed when both 1G and 2M hugepage is set
>> after "numa=off".
>> cmdline hugepage settings:
>> hugepagesz=1G hugepages=0:3,1:3
>> hugepagesz=2M hugepages=0:1024,1:1024
>> results:
>> HugeTLB registered 1.00 GiB page size, pre-allocated 0 pages
>> HugeTLB registered 2.00 MiB page size, pre-allocated 1024 pages
>>
>> Furthermore, confusing behavior can be also observed when invalid
>> node behind valid node.
>>
>> To fix this, hugetlb_hstate_alloc_pages should be called even when
>> hugepages_setup going to invalid.
> Shouldn't we bail out if someone requests node-specific allocations but
> we are not running with NUMA?
>
> What's the result after your change?
>
>> Cc: <stable@vger.kernel.org>
> I am not sure if this is really stable material.
This change will make 1G-huge-page consistent with 2M-huge-page when
an invalid node is configured. After this patch, all per node huge pages
will allocate until an invalid node.
Thus, the basic question is "what will lead to an invalid node".
1) Some debugging and test cases as Mike suggested.
2) When part of physical memory or cpu is broken and bios not report
the node with physical damage, but still use the original grub.
next prev parent reply other threads:[~2022-04-02 2:37 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-01 10:12 [PATCH v2 0/2] hugetlb: Fix confusing behavior Peng Liu
2022-04-01 10:12 ` [PATCH v2 1/2] hugetlb: Fix hugepages_setup when deal with pernode Peng Liu
2022-04-01 10:43 ` David Hildenbrand
2022-04-01 17:23 ` Mike Kravetz
2022-04-04 10:41 ` David Hildenbrand
2022-04-04 23:48 ` Mike Kravetz
2022-04-02 2:36 ` liupeng (DM) [this message]
2022-04-01 10:12 ` [PATCH v2 2/2] hugetlb: Fix return value of __setup handlers Peng Liu
2022-04-01 10:46 ` David Hildenbrand
2022-04-02 1:33 ` liupeng (DM)
2022-04-04 10:25 ` David Hildenbrand
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=6900c697-2eaa-9e91-4d37-7a11c71d021f@huawei.com \
--to=liupeng256@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mike.kravetz@oracle.com \
--cc=stable@vger.kernel.org \
--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