Re: [PATCH] mm/mglru: force aging the lruvec when min_seq pinned

[Barry Song]

On Thu, Jul 30, 2026 at 7:22 PM Zhaoyang Huang <huangzhaoyang@xxxxxxxxx> wrote:
>
> On Thu, Jul 30, 2026 at 5:41 PM Barry Song <baohua@xxxxxxxxxx> wrote:
> >
> > On Thu, Jul 30, 2026 at 5:35 PM Zhaoyang Huang <huangzhaoyang@xxxxxxxxx> wrote:
> > >
> > > On Thu, Jul 30, 2026 at 5:31 PM Barry Song <baohua@xxxxxxxxxx> wrote:
> > > >
> > > > On Thu, Jul 30, 2026 at 5:20 PM Zhaoyang Huang <huangzhaoyang@xxxxxxxxx> wrote:
> > > > [...]
> > > > > >
> > > > > > This is very weird. This seems like using a sledgehammer to kill a fly :-)
> > > > > >
> > > > > > Do you mean that isolate_folio() fails, the folio is put back
> > > > > > into the oldest generation, and the next time it is scanned, it
> > > > > > still fails to be isolated? As a result, scan_folios() makes
> > > > > > no progress at all?
> > > > > > And is it because the oldest generation contains only this
> > > > > > folio, leaving no other folios for scan_folios() to scan?
> > > > > >
> > > > > > Why can't you simply promote the folio?
> > > > > > Do you know why isolate_folio() keeps failing? I suspect it's
> > > > > > because folio_try_get(folio) fails repeatedly?
> > > > > Yes. As described in commit message, the orphan folio is an abnormal
> > > > > one as it is on page cache but has folio->refcount=0 which makes it
> > > > > isolated and putback to lru forever and finally be the only one in
> > > > > min_seq. IMO, MGLRU should keep make progress with bringing this
> > > > > orphan folio together with.
> > > > > >
> > > >
> > > > Why is a folio with folio->refcount == 0 still in the page
> > > > cache? Can this be fixed at the source instead?
> > > Yes, it is a bug and should be fixed. But I think it should not affect
> > > LRU in this way while the legacy LRU could move forward in the same
> > > scenario.
> >
> > Yes. But, if there is a real problem, a folio could always fail in
> > isolate_folio(), or keep failing for a long time before it can
> > finally be isolated successfully.
> >
> > I agree that we could apply a similar approach, for example,
> > promoting the folio to the second-oldest generation instead.
> >
> > However, if this problem doesn't actually exist, it seems we're
> > trying to fix something that isn't a real issue.
> It is a real issue that some android vendors run across recently in
> v6.18 under truncate and fs's gc test case. Some vendors even switch
> back to legacy LRU partly because of this issue.

I understand your point. However, the underlying issue still exists:
a page cache folio with a zero refcount is not a valid state and
should be fixed directly.
We should address the root cause instead of working around the issue
here. The workaround also adds too much complexity.
The active/inactive LRU has
shrink_active_list() to ensure that the inactive list does not become
too small, which happens to avoid this problem. MGLRU does not have
such a mechanism, but this is not a problem of MGLRU.

For a workaround in the GKI hook, would it be possible to detect
this situation in should_run_aging() instead?
For example, if there is only one folio and it has a refcount of 0,
and we are already at a high reclaim priority (sc->priority), could
we return true from should_run_aging() in this case?