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

[Zhaoyang Huang]

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.