Re: [RFC PATCH v3 0/4] mm: enable lru cache for smaller large folios
From: Barry Song
Date: Thu Aug 20 2026 - 16:22:33 EST
On Fri, Aug 21, 2026 at 4:18 AM Barry Song <baohua@xxxxxxxxxx> wrote:
>
> On Fri, Aug 21, 2026 at 2:23 AM David Hildenbrand (Arm)
> <david@xxxxxxxxxx> 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/20260806-lru_cache_drain_for_folio-v1-1-c6287d295e99@xxxxxxxxxx
> > )
> >
> > 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/20260818225904.55236-4-baohua@xxxxxxxxxx/
>
> Best Regards
> Barry