Re: [PATCH v3] mm: migrate: requeue destination folio on deferred split queue

[SeongJae Park <sj@kernel.org>]

On Sat, 14 Mar 2026 15:40:42 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:

> On Fri, 13 Mar 2026 13:40:29 +0300 Usama Arif <usama.arif@linux.dev> wrote:
> 
> > 
> > 
> > On 13/03/2026 03:52, Andrew Morton wrote:
> > > On Thu, 12 Mar 2026 17:16:30 -0700 SeongJae Park <sj@kernel.org> wrote:
> > > 
> > >>> By the time migrate_folio_move() runs, partially mapped folios without a
> > >>> pin have already been split by migrate_pages_batch().  So only two cases
> > >>> remain on the deferred list at this point:
> > >>>   1. Partially mapped folios with a pin (split failed).
> > >>>   2. Fully mapped but potentially underused folios.
> > >>> The recorded partially_mapped state is forwarded to deferred_split_folio()
> > >>> so that the destination folio is correctly re-queued in both cases.
> > >>>
> > >>> Reported-by: Johannes Weiner <hannes@cmpxchg.org>
> > >>> Fixes: dafff3f4c850 ("mm: split underused THPs")
> > >>
> > >> Seems the commit is merged in 6.12.  And I assume the user impact on
> > >> THP-shrinker enabled systems is visible.  If so, should we Cc stable@ ?
> > > 
> > > I think the user impact should be visible to backport, but the
> > > changelog is elusive on details?
> > > 
> > 
> > 
> > The original patches added THPs to deferred_list at fault/collapse, they
> > got removed but not added back to the list after migration.
> > This patch adds them to the deferred_list on migration. The user would
> > not expect the THPs to get removed from deferred_list on migration, so
> > this fixes user expectations.
> 
> Maybe users just won't notice?

My guess of the user-visible consequence was like following.  Because THPs are
removed from the deferred_list, THP shinker cannot split the underutilized THPs
in time.  As a result, users will show less free memory than before.  I believe
I might be wrong and Usama can correct me in the case.


Thanks,
SJ

[...]