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

[Barry Song]

On Fri, Aug 21, 2026 at 10:18 PM David Hildenbrand (Arm)
<david@xxxxxxxxxx> wrote:
>
> On 8/20/26 22:18, Barry Song 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?
>
> I think we should not consider your patch set until Hugh either resolved it or
> we have a better way to handle draining. Building on top of this for large
> folios now just gets painful.

Sure, I’m perfectly fine with this. I swear I asked Hugh whether I
should suspend this job and wait for him, but he didn’t seem to suggest
suspending it. :-) However, I agree that it makes more sense to
prioritize Hugh’s job before this one.

>
> > We might end up doing some extra draining in that case,
> > but that's safe—any value greater than 1 might not be.
>
> We'll unconditionally drain all LRU caches, which is precisely *not* what we
> want to do in the first place. :)

Sure. Maybe because the test case is a kernel build, the
collect_longterm_unpinnable_folios() path is not really a hot path.
But I agree we can probably find some workloads where it is hot.

I’m perfectly fine with putting this large folio lru_cache work on hold
and working with Hugh on optimizing those drain paths first. :-)

Best Regards
Barry