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

[Barry Song]

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?

static bool map_pte(struct page_vma_mapped_walk *pvmw, pmd_t *pmdvalp,
                    spinlock_t **ptlp)
{
        bool is_migration;
        pte_t ptent;

        if (pvmw->flags & PVMW_SYNC) {
                /* Use the stricter lookup */
                pvmw->pte = pte_offset_map_lock(pvmw->vma->vm_mm, pvmw->pmd,
                                                pvmw->address, &pvmw->ptl);
                *ptlp = pvmw->ptl;
                return !!pvmw->pte;
        }
       ...
}

Am I missing something?

Best,
Barry