Re: [PATCH] mm: synchronize with PTE table reclaim for all folio sizes

[Baolin Wang]

On 11/6/26 5:56 PM, Barry Song wrote:
> On Fri, Nov 6, 2026 at 4:55 PM Baolin Wang
> <baolin.wang@xxxxxxxxxxxxxxxxx> wrote:
> [...]
> > > > > Ouch ... one thing I missed ... what about order-0 reclaim?
> > > > >
> > > > > shrink_folio_list() only sets TTU_SYNC for large folio, so can't we still
> > > > > hit the same race there?
> > > >
> > > > Thanks Lance. But this matches the purpose of the TTU_SYNC flag, which
> > > > is used to avoid racy checks with PVMW_SYNC. If no TTU_SYNC flag is set,
> > > > it means the caller can tolerate some racy checks.
> > > >
> > > > For this case, I think we should set TTU_SYNC unconditionally in
> > > > shrink_folio_list(). Barry, what do you think?
> > >
> > > Baolin, thanks for reaching out to me. I added that flag
> > > mainly for large folios.
> > >
> > > I observed cases where PTEs for large folios are partially
> > > cleared during certain transition states, for example, when
> > > PTEs are cleared before being modified:
> > >
> > > pte = ptep_get_and_clear();
> > > pte modification;
> > > set_pte_at();
> > >
> > > In such cases, page_vma_mapped_walk() skips the empty
> > > entries and starts from the next valid one.
> > >
> > > This may result in partially unmapping PTEs for large folios
> > > and trigger unexpected folio splits. At the time, I was
> > > particularly concerned about unnecessary folio splitting,
> > > so my focus was mainly on large folios.
> >
> > Thanks for the information.
> >
> > > However, I also noticed that a similar race can occur with
> > > small folios. In that case, the folio may simply remain
> > > unreclaimed by the reclamation path.
> > >
> > > However, my main concern at the time was avoiding
> > > unnecessary folio splits.
> > >
> > > Your new race also seems to amplify the same situation.
> > > However, I don't think this problem necessarily depends on
> > > the commit you mentioned. It has been around for a long time.
> >
> > Agree.
> >
> > > If the concern is reclaim failure, I agree that there is no
> > > fundamental difference between large folios and small folios.
> >
> > OK. And I did a quick measurement to reclaim anon and file folios via
> > the memory.reclaim interface.
> >
> >   From test results, reclaiming 1G small anonymous folios (using zram as
> > swap) shows no significant performance change. However, reclaiming 1G
> > mapped clean small file folios does show an observable regression if the
> > TTU_SYNC flag is set.
> >
> > Without TTU_SYNC for small folios:
> > time echo 1G > /sys/fs/cgroup/test/memory.reclaim
> > real    0m0.178s
> > user    0m0.000s
> > sys     0m0.178s
> >
> > With TTU_SYNC for small folios:
> > real    0m0.315s
> > user    0m0.000s
> > sys     0m0.314s
> >
> > So for the current patch, I'd prefer to keep things as is: only sync
> > when TTU_SYNC is set. Without setting the TTU_SYNC flag, keep the
> > original logic, meaning the caller can tolerate some racy checks.
> >
> > Any other thoughts?
>
> I'm still struggling to understand where the regression comes
> from. You're doing echo 1G > /sys/fs/cgroup/test/memory.reclaim
> without the concurrent CPU 1 (MADV_DONTNEED) operation that
> causes the race.
>
> so the regression actually comes from other places, maybe here?

Yes, I think so. But I haven't had time to dig into how this affects my 
tests yet. I'll dig into this later.