All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
To: Johannes Weiner <hannes@cmpxchg.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: Wed, 1 Jul 2026 20:14:05 +0200	[thread overview]
Message-ID: <c00f2d42-83f7-4417-aaf8-aed0bf1e28db@kernel.org> (raw)
In-Reply-To: <akUyEgKMryy6TntY@cmpxchg.org>

On 7/1/26 17:28, Johannes Weiner wrote:
> On Wed, Jul 01, 2026 at 04:19:29PM +0200, Vlastimil Babka (SUSE) wrote:
>> On 6/26/26 20:21, Johannes Weiner wrote:
>> > While trying to fix a reclaim storm in defrag_mode, I noticed that
>> > non-movable direct compaction is extremely inefficient.
>> > 
>> > When searching for space to evacuate, compaction only allows blocks of
>> > the same type as the incoming request. This is to prevent migratetype
>> > pollution, where a small non-movable request frees space in a movable
>> > block and provokes the allocator to fall back and pollute it.
>> > 
>> > This protection is reasonable on one hand, but the downside is that it
>> > makes non-movable direct compaction nearly useless: if we get the type
>> > annotations right, by definition there aren't any movable pages inside
>> > the non-movable blocks it is allowed to scan.
>> > 
>> > With defrag_mode, the goal is the production of whole blocks, which
>> > are essentially type neutral: __rmqueue_claim() will convert them
>> > wholesale on alloc. This makes type mixing and pollution a non-issue.
>> > 
>> > Fix the pollution gates to take the requested order into account, and
>> > allow whole-block requests to scan blocks of other types.
>> > 
>> > The only exception is CMA blocks. That type is sticky and these blocks
>> > cannot be claimed to other types. Continue to be strict with them, and
>> > allow only explicit ALLOC_CMA requests and kcompactd to evacuate them.
>> > 
>> > Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
>> 
>> Reviewed-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> 
> Thanks!
> 
>> > diff --git a/mm/compaction.c b/mm/compaction.c
>> > index f08765ade014..7df3a85d43af 100644
>> > --- a/mm/compaction.c
>> > +++ b/mm/compaction.c
>> > @@ -1381,12 +1381,33 @@ static bool suitable_migration_source(struct compact_control *cc,
>> >  	if (pageblock_skip_persistent(page))
>> >  		return false;
>> >  
>> > -	if ((cc->mode != MIGRATE_ASYNC) || !cc->direct_compaction)
>> > +	/*
>> > +	 * Background compaction produces blocks for the zone at
>> > +	 * large, with no particular allocation context. Allow all
>> > +	 * block types, including CMA.
>> > +	 */
>> > +	if (!cc->direct_compaction)
>> >  		return true;
>> >  
>> >  	block_mt = get_pageblock_migratetype(page);
>> >  
>> > -	if (cc->migratetype == MIGRATE_MOVABLE)
>> > +	/*
>> > +	 * CMA pages can only be taken by ALLOC_CMA requests. For anybody
>> > +	 * else, vacating a CMA block consumes free pages the caller
>> > +	 * could have used, and produces free pages it cannot.
>> > +	 */
>> > +	if (is_migrate_cma(block_mt) && !(cc->alloc_flags & ALLOC_CMA))
>> > +		return false;
>> > +
>> > +	if (cc->mode != MIGRATE_ASYNC)
>> > +		return true;
>> 
>> This now stands out as uncommented. Can we come up with a rationale? :)
> 
> Let's see. Originally it came from here:
> 
> commit 9927af740b1b9b1e769310bd0b91425e8047b803
> Author: Mel Gorman <mel@csn.ul.ie>
> Date:   Thu Jan 13 15:45:59 2011 -0800
> 
>     mm: compaction: perform a faster migration scan when migrating asynchronously
> 
> This limited async scanners to movable blocks. By keeping them to the
> most productive space, it keeps their latencies down.
> 
> But then there was a follow up here:
> 
> commit 282722b0d258ec23fc79d80165418fee83f01736
> Author: Vlastimil Babka <vbabka@kernel.org>
> Date:   Mon May 8 15:54:49 2017 -0700
> 
>     mm, compaction: restrict async compaction to pageblocks of same migratetype

Aha :)

> 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?).

>  This is high-effort,
> 	 * low-result work. Restrict it to sync scans.
> 	 */

Works for me.



  reply	other threads:[~2026-07-01 18:14 UTC|newest]

Thread overview: 16+ 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-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) [this message]
2026-07-01 21:11         ` 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-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

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=c00f2d42-83f7-4417-aaf8-aed0bf1e28db@kernel.org \
    --to=vbabka@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=david@kernel.org \
    --cc=hannes@cmpxchg.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=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.