Re: [RFC PATCH v3 0/4] mm: enable lru cache for smaller large folios

On Fri, Aug 21, 2026 at 4:18 AM Barry Song <[email protected]> wrote:
>
> On Fri, Aug 21, 2026 at 2:23 AM David Hildenbrand (Arm)
> <[email protected]> wrote:
> >
> > On 8/19/26 00:59, Barry Song (Xiaomi) wrote:
> > > This patchset enables the per-CPU LRU cache for large folios with fewer
> > > than `FOLIO_BATCH_SIZE` (31) pages. It also limits each per-CPU LRU cache
> > > to at most `FOLIO_BATCH_SIZE` pages to avoid negatively affecting
> > > accounting and memory reclamation pressure.
> > >
> > > This is particularly beneficial on systems that use relatively small
> > > large folios. For larger folios, the benefit is likely to be smaller
> > > because far fewer folios are expected to contend for the LRU cache.
> >
> > As raised, there is this problem with collect_longterm_unpinnable_folios()
> >
> > (see
> > https://lore.kernel.org/r/[email protected]
> > )
> >
> > whereby we don't know how many refs we actually hold. Certainly not 1.
> >
> > We might have to wait for Hugh's cleanup to handle that cleanly (and avoid all
> > the other LRU cache draining).
>
> Hi David,
> Thanks for raising this.
> Yes, I saw your comment and took a closer look at it. I think the
> best approach for now is to leave that part untouched until Hugh's
> patch lands? We might end up doing some extra draining in that case,
> but that's safe—any value greater than 1 might not be. We may just
> drain more than necessary?

BTW, David. This is also why I didn't move the below checks in patch 3/4[1]
to lru_cache_drain_for_folio() as we are not safe to do it for that "1" in
collect_longterm_unpinnable_folios():

+ if (folio_ref_count(folio) == folio_expected_ref_count(folio) + 1 +
+    folio_may_be_lru_cached(folio))
+ lru_cache_drain_for_folio(folio, 1, NULL);

[1] https://lore.kernel.org/all/[email protected]/

>
> Best Regards
> Barry