Re: [PATCH v2 1/2] mm/huge_memory.c: skip zero-page remapping when underused THP shrinker is disabled

[Nico Pache]

On 10/26/26 2:58 PM, Barry Song wrote:
> On Tue, Oct 27, 2026 at 4:02 AM Nico Pache <nico.pache@xxxxxxxxx> wrote:
> > On 10/25/26 10:52 PM, Barry Song wrote:
> > > On Mon, Oct 26, 2026 at 5:48 AM Nico Pache <nico.pache@xxxxxxxxx> wrote:
> > > > On 10/25/26 2:28 PM, Barry Song wrote:
> > > > > On Mon, Oct 26, 2026 at 1:40 AM Nico Pache (Red Hat)
> > > > > <nico.pache@xxxxxxxxx> wrote:
> > > > > > The zero-page remapping in __folio_split() was added to support the
> > > > > > underused THP shrinker. When the shrinker is disabled via
> > > > > > shrink_underused, gate TTU_USE_SHARED_ZEROPAGE on split_underused_thp
> > > > > > to avoid scanning subpages for zero content unnecessarily.
> > > > > >
> > > > > > Suggested-by: David Hildenbrand <david@xxxxxxxxxx>
> > > > > > Fixes: b1f202060afe ("mm: remap unused subpages to shared zeropage when splitting isolated thp")
> > > > > > Signed-off-by: Nico Pache <nico.pache@xxxxxxxxx>
> > > > >
> > > > > is b1f202060afe a correct fixes tag? as
> > > > > commit b1f202060afe has no even "split_underused_thp" there.
> > > >
> > > > I believe so. IIUC these two series were merged together. While
> > > > 81d3ff3c6f7 introduces the toggle, b1f202060afe is where the behavior
> > > > started.
> > > >
> > > > I guess you could argue that the Fixes should include both?
> > > >
> > > > Not entirely sure!
> > >
> > > Thanks for the clarification. I guess it's fine.
> > >
> > > BTW, with the code below, we no longer add fully mapped
> > > folios to deferred_split_folio. So the scanning code only
> > > handles partially mapped folios to set up zero-page mappings
> > > for their subpages.
> > >
> > > I'm still not quite sure whether this is really harmful, though.
> > > Am I missing something, or was there some discussion I missed?
> >
> > The issue is not in the actual shrinker code or the deferred split list.
> >
> > The issue is that any split leads to this zero-page remapping
> > indiscriminate of the actual toggle. The same way this toggle is gating
> > things going on the deferred split list, we should be gating the actual
> > zero-page remapping too.
>
> I'm not quite sure this is true. The toggle prevents fully mapped
> folios from being added to the deferred split list, so their
> subpages won't have a chance to be remapped to zero.

Correct, but the deferred split list is not the only caller of 
folio_split(); all other callers get unconditional zero page remapping.

Additionally theres a difference between being fully mapped (and zero), 
and being partially unmapped. the zero-page remapping checks the content 
of the page. We could add folios to the deferred split list that are 
fully mapped but contain mostly zeros. With shrinker_underused turned 
off we no longer do any underutilized scans on reclaim, but other 
splitters (KSM, vmscan, migration, etc) will still scan the content of 
the memory and do the remapping whether this is on or off.
 >
> For the remaining folios that are not fully mapped, or those
> that were added to deferred_split_list while the toggle was
> on and remain there after it is switched off, allowing
> remapping to zeropfn doesn't seem to violate the toggle's
> intention of preventing fully mapped folios from being added
> to deferred_split_list.
>
> Anyway, I don't have a strong opinion on this.

I think theres a misunderstanding here, but hopefully the above clears 
it up :) if not just lmk!

Cheers,
-- Nico


> Thanks!
> Barry