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

[David Hildenbrand (Arm)]

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 "!=".

> +			return false;
> +		/*
> +		 * A global LRU drain is too expensive, but a local drain
> +		 * can still be beneficial. For example, large folios that
> +		 * have just been swapped in and fall back from
> +		 * do_swap_page() to do_wp_page() are likely still in this
> +		 * CPU's LRU cache.
> +		 */

Do we really need that comment? It's just the same as we have in
wp_can_reuse_anon_folio(). So either drop it or use the same comment.

I was wondering whether we could unify some logic with
wp_can_reuse_anon_folio(), but the checks are just to different.


Apart from that LGTM. I'm sure there are some micro-optimizations to be had, but
this here should suffice.

-- 
Cheers,

David