From: Johannes Weiner <hannes@cmpxchg.org>
To: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Brendan Jackman <jackmanb@google.com>, Zi Yan <ziy@nvidia.com>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Mike Rapoport <rppt@kernel.org>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] mm: compaction: support non-movable compaction for pageblock requests
Date: Thu, 9 Jul 2026 13:39:32 -0400 [thread overview]
Message-ID: <ak_c1HH72sJDmaSZ@cmpxchg.org> (raw)
In-Reply-To: <61bc1ad0-f9e3-405a-ae32-b89bcdd2e1d1@kernel.org>
On Thu, Jul 02, 2026 at 11:28:47AM +0200, Vlastimil Babka (SUSE) wrote:
> On 7/1/26 23:11, Johannes Weiner wrote:
> > On Wed, Jul 01, 2026 at 08:14:05PM +0200, Vlastimil Babka (SUSE) wrote:
> >>
> >> > This made the migratetype filtering about preventing block
> >> > pollution. The patch quotes reduced extfrag numbers.
> >> >
> >> > So now we have a block pollution guard that we apply only if... the
> >> > scanner is latency sensitive? :) Is this actually desired behavior?
> >>
> >> Yeah indeed I was wondering in this direction.
> >>
> >> > Another way of looking at it would be this:
> >> >
> >> > /*
> >> > * Allocation fallbacks can spread migratable pages
> >> > * into non-movable blocks.
> >>
> >> But also vice versa, non-movable pages into movable blocks? (without
> >> defrag_mode?).
> >
> > Uhm but those aren't compactable anymore then, right?
>
> Yeah.
>
> > There is a flipside, but it isn't quite symmetrical. Movable requests
> > are allowed to look for movables in unmovable blocks once they become
> > sync (high-effort, low-result). Non-movable requests are finally
> > allowed to empty movable blocks once they become sync; they *start*
> > with the high-effort, low-result mode to avoid block contamination but
> > are allowed to escalate when that doesn't produce results.
>
> Hm, true!
>
> I was also thinking, if defrag mode doesn't allow that escalation ever
> (IIRC?), should it be reflected here as well even with sync compaction?
Ok I made a clarification regarding defrag_mode in the other comment.
How about this?
diff --git a/mm/compaction.c b/mm/compaction.c
index 7df3a85d43af..a12a49eefe85 100644
--- a/mm/compaction.c
+++ b/mm/compaction.c
@@ -1399,13 +1399,24 @@ static bool suitable_migration_source(struct compact_control *cc,
if (is_migrate_cma(block_mt) && !(cc->alloc_flags & ALLOC_CMA))
return false;
+ /*
+ * Per default, scans are restricted to blocks compatible with
+ * the request, to prevent cross-contamination. Once
+ * compaction priority escalates to synchronous scans, though,
+ * scan all blocks to try to make forward progress. For
+ * movable request, this likely helps little: there shouldn't
+ * be many migratable pages inside non-movable blocks besides
+ * allocator fallbacks. For non-movable requests, this helps a
+ * lot, as they can finally scan movable blocks.
+ */
if (cc->mode != MIGRATE_ASYNC)
return true;
/*
* Prevent small unmovable/reclaimable requests from polluting
- * movable blocks through fallbacks. Whole-block production is
- * exempt as the allocator claims and converts these.
+ * movable blocks through fallbacks. Whole-block production
+ * (directly requested, or defrag_mode) is exempt as the
+ * allocator claims and converts these.
*/
if (cc->migratetype == MIGRATE_MOVABLE || cc->order >= pageblock_order)
return is_migrate_movable(block_mt);
next prev parent reply other threads:[~2026-07-09 17:42 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-26 18:21 [PATCH 0/4] mm: fix reclaim storms in defrag_mode Johannes Weiner
2026-06-26 18:21 ` [PATCH 1/4] mm: page_alloc: __GFP_FS lockdep annotation for direct compaction Johannes Weiner
2026-07-01 13:45 ` Vlastimil Babka (SUSE)
2026-07-02 0:39 ` Shakeel Butt
2026-06-26 18:21 ` [PATCH 2/4] mm: compaction: support non-movable compaction for pageblock requests Johannes Weiner
2026-07-01 14:19 ` Vlastimil Babka (SUSE)
2026-07-01 15:28 ` Johannes Weiner
2026-07-01 18:14 ` Vlastimil Babka (SUSE)
2026-07-01 21:11 ` Johannes Weiner
2026-07-02 9:28 ` Vlastimil Babka (SUSE)
2026-07-09 17:39 ` Johannes Weiner [this message]
2026-07-09 20:42 ` Vlastimil Babka (SUSE)
2026-07-02 1:47 ` Zi Yan
2026-07-09 17:42 ` Johannes Weiner
2026-06-26 18:21 ` [PATCH 3/4] mm: page_alloc: move capture_control to the page allocator Johannes Weiner
2026-07-01 18:02 ` Vlastimil Babka (SUSE)
2026-07-01 20:57 ` Johannes Weiner
2026-07-02 10:20 ` Vlastimil Babka (SUSE)
2026-07-09 17:45 ` Johannes Weiner
2026-07-09 20:44 ` Vlastimil Babka (SUSE)
2026-06-26 18:21 ` [PATCH 4/4] mm: page_alloc: fix non-movable reclaim storm in defrag_mode Johannes Weiner
2026-06-26 18:29 ` Zi Yan
2026-06-26 18:43 ` Johannes Weiner
2026-07-01 18:06 ` Vlastimil Babka (SUSE)
2026-07-01 21:02 ` Johannes Weiner
2026-07-02 0:31 ` [PATCH 0/4] mm: fix reclaim storms " Shakeel Butt
2026-07-09 17:51 ` Johannes Weiner
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=ak_c1HH72sJDmaSZ@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=jackmanb@google.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=rppt@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 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.