From: Mike Kravetz <mike.kravetz@oracle.com>
To: Andrew Morton <akpm@linux-foundation.org>,
Barry Song <song.bao.hua@hisilicon.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
linuxarm@huawei.com,
Jonathan Cameron <jonathan.cameron@huawei.com>,
Roman Gushchin <guro@fb.com>
Subject: Re: [PATCH v3] mm/hugetlb: avoid hardcoding while checking if cma is enable
Date: Wed, 8 Jul 2020 10:45:16 -0700 [thread overview]
Message-ID: <9066e009-5ed2-1992-d70d-fd27b4bf5871@oracle.com> (raw)
In-Reply-To: <20200707125641.dbd2ccd63f525aa5870069d8@linux-foundation.org>
On 7/7/20 12:56 PM, Andrew Morton wrote:
> On Tue, 7 Jul 2020 16:02:04 +1200 Barry Song <song.bao.hua@hisilicon.com> wrote:
>
>> hugetlb_cma[0] can be NULL due to various reasons, for example, node0 has
>> no memory. so NULL hugetlb_cma[0] doesn't necessarily mean cma is not
>> enabled. gigantic pages might have been reserved on other nodes.
>
> I'm trying to figure out whether this should be backported into 5.7.1,
> but the changelog doesn't describe any known user-visible effects of
> the bug. Are there any?
Barry must have missed this email. He reported the issue so I was hoping
he would reply.
Based on the code changes, I believe the following could happen:
- Someone uses 'hugetlb_cma=' kernel command line parameter to reserve
CMA for gigantic pages.
- The system topology is such that no memory is on node 0. Therefore,
no CMA can be reserved for gigantic pages on node 0. CMA is reserved
on other nodes.
- The user also specifies a number of gigantic pages to pre-allocate on
the command line with hugepagesz=<gigantic_page_size> hugepages=<N>
- The routine which allocates gigantic pages from the bootmem allocator
will not detect CMA has been reserved as there is no memory on node 0.
Therefore, pages will be pre-allocated from bootmem allocator as well
as reserved in CMA.
This double allocation (bootmem and CMA) is the worst case scenario. Not
sure if this is what Barry saw, and I suspect this would rarely happen.
After writing this, I started to think that perhaps command line parsing
should be changed. If hugetlb_cma= is specified, it makes no sense to
pre-allocate gigantic pages. Therefore, the hugepages=<N> paramemter
should be ignored and flagged with a warning if hugetlb_cma= is specified.
This could be checked at parsing time and there would be no need for such
a check in the allocation code (except for sanity cheching).
Thoughts? I just cleaned up the parsing code and could make such a change
quite easily.
--
Mike Kravetz
next prev parent reply other threads:[~2020-07-08 17:46 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-07 4:02 [PATCH v3] mm/hugetlb: avoid hardcoding while checking if cma is enable Barry Song
2020-07-07 8:18 ` Mike Rapoport
2020-07-07 19:56 ` Andrew Morton
2020-07-08 17:45 ` Mike Kravetz [this message]
2020-07-08 18:46 ` Roman Gushchin
2020-07-08 22:11 ` Song Bao Hua (Barry Song)
2020-07-09 18:58 ` Mike Kravetz
2020-07-09 23:45 ` Song Bao Hua (Barry Song)
2020-07-10 0:24 ` 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=9066e009-5ed2-1992-d70d-fd27b4bf5871@oracle.com \
--to=mike.kravetz@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=guro@fb.com \
--cc=jonathan.cameron@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxarm@huawei.com \
--cc=song.bao.hua@hisilicon.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).