Re: [PATCH] mm/mglru: deactivate anon folios into the oldest generation

[Kairui Song <ryncsn@gmail.com>]

On Thu, Nov 12, 2026 at 04:19:28PM +0800, Ridong Chen wrote:
> From: Ridong Chen <chenridong@xiaomi.com>
> 
> folio_deactivate() is used by MADV_COLD and DAMOS_LRU_DEPRIO to move a
> folio towards eviction. lru_deactivate() does that by deleting the folio
> from its LRU list, clearing PG_active and PG_referenced, and adding it
> back with lruvec_add_folio().
> 
> With MGLRU, lru_gen_folio_seq() places a swap-backed folio that is not
> in the swap cache, i.e. an anon or shmem folio, into max_seq - 1,
> regardless of its refs. That generation is active per
> lru_gen_is_active(), so such a folio never reaches an inactive
> generation, and a folio that has aged into min_seq + 1 is moved to a
> younger generation instead. PGDEACTIVATE is still counted. Other folios
> are not affected: with their refs cleared they are placed into the
> oldest generation.
> 
> On a 4-generation memcg, 64MB of aged anon memory in min_seq + 1 ends up
> in max_seq - 1 after MADV_COLD, while 64MB of file memory in the same
> generation ends up in min_seq.
> 
> As a result, MADV_COLD can make anon memory less likely to be reclaimed.
> It can be reproduced with a single process in a memcg with swap enabled:
> 
>   1) map two 64MB anon regions A and B and fault them in, A first;
>   2) age the memcg twice through /sys/kernel/debug/lru_gen, so that both
>      regions are in the same generation, min_seq + 1;
>   3) apply MADV_COLD to B only, A is the control;
>   4) reclaim the size of one region from anon only:
>      echo "64M swappiness=max" > memory.reclaim;
>   5) count the swapped out pages of A and B from /proc/self/pagemap.
> 
> B is expected to be swapped out instead of A. Three runs on mm-new:
> 
>                      A swapped out        B (MADV_COLD) swapped out
>   before             16384 pages          15 ~ 128 pages
>   after              0 ~ 157 pages        16384 pages
> 
> Use lruvec_add_folio_tail() for MGLRU, which treats the folio as
> reclaiming and adds it to the tail of the oldest generation, the same
> place lru_deactivate_file() puts a clean file folio. The other folios,
> which were added to the head of the oldest generation, are now added to
> its tail as well, so they are reclaimed first as MADV_COLD intends.
> 
> Fixes: 081488051d28 ("mm/mglru: fix underprotected page cache")
> Signed-off-by: Ridong Chen <chenridong@xiaomi.com>
> ---

...

> 
>  mm/folio.c | 11 ++++++++++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/folio.c b/mm/folio.c
> index ea3adb6a89d7..c412d9b398e4 100644
> --- a/mm/folio.c
> +++ b/mm/folio.c
> @@ -583,7 +583,16 @@ static void lru_deactivate(struct lruvec *lruvec, struct folio *folio)
>  	lruvec_del_folio(lruvec, folio);
>  	folio_clear_active(folio);
>  	folio_clear_referenced(folio);
> -	lruvec_add_folio(lruvec, folio);
> +	/*
> +	 * For MGLRU, lruvec_add_folio() places anon folios that are not in
> +	 * the swap cache into the second youngest generation, which is an
> +	 * active one. Add the folio to the oldest generation instead, like
> +	 * lru_deactivate_file() does for clean folios.
> +	 */
> +	if (lru_gen_enabled())
> +		lruvec_add_folio_tail(lruvec, folio);
> +	else
> +		lruvec_add_folio(lruvec, folio);

Hi Ridong,

One question here, why MGLRU/CLRU have to use two different ways to
add the folio back?  Will this cause over aggressive reclaim of the
folio?