Re: [RFC PATCH v2 2/2] mm: improve large folio reuse for LRU-cached folios

[David Hildenbrand (Arm)]

On 8/3/26 09:24, Barry Song wrote:
> On Wed, Jul 29, 2026 at 8:11 PM David Hildenbrand (Arm)
> <david@xxxxxxxxxx> wrote:
>>
>> On 7/9/26 10:15, Barry Song (Xiaomi) wrote:
>>> Large folios may now reside in the per-CPU LRU cache. Before
>>> attempting to reuse them, drain the local LRU cache, which
>>> can still be beneficial in cases where the folios are likely
>>> to remain in this CPU's LRU cache:
>>>
>>> int main(int argc, char *argv[])
>>> {
>>>     int i;
>>>     while (1) {
>>>         volatile int *p = mmap(0, SIZE, PROT_READ | PROT_WRITE,
>>>                                MAP_PRIVATE | MAP_ANONYMOUS,
>>>                                -1, 0);
>>>         for (int i = 0; i < SIZE / sizeof(int); i++)
>>>             p[i] = i;
>>>         madvise((void *)p, SIZE, MADV_PAGEOUT);
>>>         if (!fork())
>>>             _exit(0);
>>>         for (int i = 0; i < SIZE / sizeof(int); i++)
>>>             p[i] = i;
>>>         munmap((void *)p, SIZE);
>>>     }
>>>     return 0;
>>> }
>>>
>>> Signed-off-by: Barry Song (Xiaomi) <baohua@xxxxxxxxxx>
>>> ---
>>>  mm/memory.c | 13 +++++++++++++
>>>  1 file changed, 13 insertions(+)
>>>
>>> diff --git a/mm/memory.c b/mm/memory.c
>>> index 5689b7cff76c..1d08ed5ba99b 100644
>>> --- a/mm/memory.c
>>> +++ b/mm/memory.c
>>> @@ -4136,6 +4136,19 @@ static bool __wp_can_reuse_large_anon_folio(struct folio *folio,
>>>               folio_unlock(folio);
>>>       }
>>>
>>> +     if (folio_may_be_lru_cached(folio) && !folio_test_lru(folio)) {
>>> +             if (folio_ref_count(folio) > folio_large_mapcount(folio) + 1)
>>
>> I assume that can just be a "!=".
> 
> I was trying to guard against the case where a folio is not on
> the LRU but also does not hold an extra reference. For example,
> the folio is off the LRU, yet
> folio_ref_count(folio) == folio_large_mapcount(folio).
> 
> In that case, we could simply reuse !folio_test_lru(folio).
> 
> Maybe such a case cannot actually happen, since paths like
> isolate_folio() take an extra reference before removing the
> folio from the LRU.
> 
> So we should be ok to just use folio_ref_count(folio) !=
> folio_large_mapcount(folio) +1
I just stumbled into something nasty last week:

https://lore.kernel.org/r/20260731-check_and_migrate_movable_folios-v1-1-e0002d7b791e@xxxxxxxxxx

For an mTHP, if we end up pinning multiple pages, calculating pin_refs is problematic and
might require us to batch over multiple pages.

But there are some nasty corner cases when just batching contiguous pages.

-- 
Cheers,

David