From: Qi Zheng <qi.zheng@linux.dev>
To: Kefeng Wang <wangkefeng.wang@huawei.com>,
muchun.song@linux.dev, osalvador@suse.de, david@kernel.org,
akpm@linux-foundation.org, azpijr@gmail.com,
lance.yang@linux.dev, Qi Zheng <zhengqi.arch@bytedance.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
stable@vger.kernel.org,
"Oscar Salvador (SUSE)" <osalvador@kernel.org>
Subject: Re: [PATCH v4 3/3] mm: hugetlb: fix GFP mask propagation to CMA
Date: Fri, 13 Nov 2026 10:30:46 +0800 [thread overview]
Message-ID: <1cd3c151-24c2-4fec-8356-99853f8d6971@linux.dev> (raw)
In-Reply-To: <7def88b4-cba5-4e8b-9e68-6069c492b582@huawei.com>
On 11/12/26 7:27 PM, Kefeng Wang wrote:
>
>
> On 11/11/2026 2:46 PM, Qi Zheng wrote:
>> From: Qi Zheng <zhengqi.arch@bytedance.com>
>>
>> cma_alloc_frozen_compound() uses GFP_KERNEL, allowing direct reclaim
>> during the first MPOL_PREFERRED_MANY allocation attempt even though
>> the caller clears __GFP_DIRECT_RECLAIM.
>
> MPOL_PREFERRED_MANY is only used for the partner allocator. Without your
It's doesn't seem so.
Gigantic surplus allocations already use MPOL_PREFERRED_MANY, following
eb02f14c4a2b ("mm/hugetlb: allow overcommitting gigantic hugepages"),
which predates 9bda131c6093.
alloc_buddy_hugetlb_folio
--> MPOL_PREFERRED_MANY
--> gfp_t gfp = gfp_mask & ~(__GFP_DIRECT_RECLAIM | __GFP_NOFAIL);
folio = alloc_surplus_hugetlb_folio(h, gfp, mpoli->nid, nodemask);
--> alloc_fresh_hugetlb_folio
--> only_alloc_fresh_hugetlb_folio
--> alloc_gigantic_frozen_folio
--> hugetlb_cma_alloc_frozen_folio
--> cma_alloc_frozen_compound
Before 9bda131c6093, cma_alloc_folio() forwarded the caller's GFP mask.
The conversion to cma_alloc_frozen_compound() replaced it with
GFP_KERNEL, re-enabling direct reclaim during the preferred-node
attempt.
Right?
Thanks,
Qi
> patches "mm: hugetlb: add CMA support for PMD-sized pages,"
> cma_alloc_frozen_compound() is only used for huge page allocations. In
> this case, I think we don't need the gfp flag, which is why I hardcoded
> it, so there's no need for the Fixes tag; this patch should be part of
> your new feature. Maybe I missed something?
>
>>
>> Pass the caller's GFP mask through the helper so CMA respects its
>> reclaim constraints when trying the preferred nodes.
>>
>> Fixes: 9bda131c6093 ("mm: cma: add cma_alloc_frozen{_compound}()")
>> Cc: stable@vger.kernel.org
>> Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>
>> Acked-by: Muchun Song <muchun.song@linux.dev>
>> Reviewed-by: Jose A. Perez de Azpillaga <azpijr@gmail.com>
>> Reviewed-by: Oscar Salvador (SUSE) <osalvador@kernel.org>
>> ---
>> include/linux/cma.h | 2 +-
>> mm/cma.c | 10 ++++++++--
>> mm/hugetlb_cma.c | 4 ++--
>> 3 files changed, 11 insertions(+), 5 deletions(-)
>>
>> diff --git a/include/linux/cma.h b/include/linux/cma.h
>> index 8555d38a97b1a..4539ea5f2c4e8 100644
>> --- a/include/linux/cma.h
>> +++ b/include/linux/cma.h
>> @@ -53,7 +53,7 @@ extern bool cma_release(struct cma *cma, const
>> struct page *pages, unsigned long
>> struct page *cma_alloc_frozen(struct cma *cma, unsigned long count,
>> unsigned int align, bool no_warn);
>> -struct page *cma_alloc_frozen_compound(struct cma *cma, unsigned int
>> order);
>> +struct page *cma_alloc_frozen_compound(struct cma *cma, unsigned int
>> order, gfp_t gfp);
>> bool cma_release_frozen(struct cma *cma, const struct page *pages,
>> unsigned long count);
>> diff --git a/mm/cma.c b/mm/cma.c
>> index 9ec1d1fd5dff5..a7c47c0e7d070 100644
>> --- a/mm/cma.c
>> +++ b/mm/cma.c
>> @@ -933,9 +933,15 @@ struct page *cma_alloc_frozen(struct cma *cma,
>> unsigned long count,
>> return __cma_alloc_frozen(cma, count, align, gfp);
>> }
>> -struct page *cma_alloc_frozen_compound(struct cma *cma, unsigned int
>> order)
>> +struct page *cma_alloc_frozen_compound(struct cma *cma, unsigned int
>> order, gfp_t gfp)
>> {
>> - gfp_t gfp = GFP_KERNEL | __GFP_COMP | __GFP_NOWARN;
>> + /*
>> + * The only caller of cma_alloc_frozen_compound() is hugetlb, and
>> + * hugetlb constructs its gfp mask via htlb_alloc_mask(), which
>> already
>> + * sets __GFP_COMP. Check here for usecases bypassing
>> htlb_alloc_mask().
>> + */
>> + if (WARN_ON_ONCE(!(gfp & __GFP_COMP)))
>> + return NULL;
>> return __cma_alloc_frozen(cma, 1 << order, order, gfp);
>> }
>> diff --git a/mm/hugetlb_cma.c b/mm/hugetlb_cma.c
>> index cd6a64986278a..3e5a30571524a 100644
>> --- a/mm/hugetlb_cma.c
>> +++ b/mm/hugetlb_cma.c
>> @@ -69,14 +69,14 @@ struct folio *hugetlb_cma_alloc_frozen_folio(int
>> order, gfp_t gfp_mask,
>> }
>> if (hugetlb_cma[nid] && node_isset(nid, *nmask))
>> - page = cma_alloc_frozen_compound(hugetlb_cma[nid], order);
>> + page = cma_alloc_frozen_compound(hugetlb_cma[nid], order,
>> gfp_mask);
>> if (!page && !(gfp_mask & __GFP_THISNODE)) {
>> for_each_node_mask(node, *nmask) {
>> if (node == nid || !hugetlb_cma[node])
>> continue;
>> - page = cma_alloc_frozen_compound(hugetlb_cma[node], order);
>> + page = cma_alloc_frozen_compound(hugetlb_cma[node],
>> order, gfp_mask);
>> if (page)
>> break;
>> }
>
prev parent reply other threads:[~2026-11-13 2:32 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 6:46 [PATCH v4 0/3] mm: hugetlb: fix CMA-related issues Qi Zheng
2026-11-11 6:46 ` [PATCH v4 1/3] x86: hugetlb: disable default CMA reservations on 32-bit kernel Qi Zheng
2026-11-11 6:46 ` [PATCH v4 2/3] mm: gup: allow long-term pins of CMA-allocated HugeTLB folios Qi Zheng
2026-11-11 7:42 ` David Hildenbrand (Arm)
2026-11-11 7:42 ` Muchun Song
2026-11-12 6:13 ` Qi Zheng
2026-11-12 8:49 ` David Hildenbrand (Arm)
2026-11-12 9:04 ` Qi Zheng
2026-11-11 6:46 ` [PATCH v4 3/3] mm: hugetlb: fix GFP mask propagation to CMA Qi Zheng
2026-11-12 11:27 ` Kefeng Wang
2026-11-12 11:30 ` Kefeng Wang
2026-11-13 2:30 ` Qi Zheng [this message]
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=1cd3c151-24c2-4fec-8356-99853f8d6971@linux.dev \
--to=qi.zheng@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=azpijr@gmail.com \
--cc=david@kernel.org \
--cc=lance.yang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=muchun.song@linux.dev \
--cc=osalvador@kernel.org \
--cc=osalvador@suse.de \
--cc=stable@vger.kernel.org \
--cc=wangkefeng.wang@huawei.com \
--cc=zhengqi.arch@bytedance.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.