Re: [RFC PATCH v3 0/4] mm: enable lru cache for smaller large folios
"David Hildenbrand (Arm)" <[email protected]>
| Newsgroups | org.kvack.linux-mm,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On 8/20/26 22:18, Barry Song 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? 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. > 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. :) -- Cheers, David