From: Andrew Morton <akpm@linux-foundation.org>
To: Qiqi Liu <liuqiqi@kylinos.cn>
Cc: vbabka@kernel.org, surenb@google.com, mhocko@suse.com,
brendan.jackman@linux.dev, hannes@cmpxchg.org, ziy@nvidia.com,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH] mm/page_alloc: apply per-task GFP context in bulk allocator
Date: Sun, 13 Sep 2026 20:23:13 -0700 [thread overview]
Message-ID: <20260913202313.6c9bf636f773fcacf573af03@linux-foundation.org> (raw)
In-Reply-To: <20260914024555.138125-1-liuqiqi@kylinos.cn>
On Mon, 14 Sep 2026 10:45:55 +0800 Qiqi Liu <liuqiqi@kylinos.cn> wrote:
> alloc_pages_bulk_noprof() does not call current_gfp_context(), so
> per-task scoped allocation constraints (PF_MEMALLOC_NOIO,
> PF_MEMALLOC_NOFS, PF_MEMALLOC_PIN) are not applied on the bulk fast
> path.
>
> The most direct consequence is PF_MEMALLOC_PIN: without clearing
> __GFP_MOVABLE, prepare_alloc_pages() selects MIGRATE_MOVABLE for the
> PCP list, and a task under memalloc_pin_save() receives movable
> pages from the bulk allocator.
Thanks.
When fixing a bug, please ensure that the changelog fully describes the
userspace-visible runtime effects of the bug.
> Fixes: 387ba26fb1cb ("mm/page_alloc: add a bulk page allocator")
> Cc: stable@vger.kernel.org
Especially when proposing a backport.
I asked $LLM this question and was told
> This can increase fragmentation and interfere with compaction or
> contiguous-memory allocations, eventually surfacing as higher
> allocation latency or allocation failures under memory pressure.
which wasn't so hard. Please update your organization's prompts to
ensure that this information is always included in changelogs. And, as
always, carefully review the LLM's output.
Other useful info to include in bugfix changelogs:
- how was this detected?
- is there a report from a real-world user? Reported-by:/Closes:
- is there a reproducer/test-case? Did the patch fix it?
prev parent reply other threads:[~2026-09-14 3:23 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-14 2:45 Qiqi Liu
2026-09-14 3:23 ` Andrew Morton [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=20260913202313.6c9bf636f773fcacf573af03@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=brendan.jackman@linux.dev \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liuqiqi@kylinos.cn \
--cc=mhocko@suse.com \
--cc=stable@vger.kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=ziy@nvidia.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
all inboxes | Powered by JetHome®