Re: [PATCH v6 26/33] mm: vmscan: prepare for reparenting MGLRU folios

[Harry Yoo (Oracle)]

On Thu, Mar 05, 2026 at 07:52:44PM +0800, Qi Zheng wrote:
> From: Qi Zheng <zhengqi.arch@xxxxxxxxxxxxx>
> 
> Similar to traditional LRU folios, in order to solve the dying memcg
> problem, we also need to reparenting MGLRU folios to the parent memcg when
> memcg offline.
> 
> However, there are the following challenges:
> 
> 1. Each lruvec has between MIN_NR_GENS and MAX_NR_GENS generations, the
>    number of generations of the parent and child memcg may be different,
>    so we cannot simply transfer MGLRU folios in the child memcg to the
>    parent memcg as we did for traditional LRU folios.
> 2. The generation information is stored in folio->flags, but we cannot
>    traverse these folios while holding the lru lock, otherwise it may
>    cause softlockup.
> 3. In walk_update_folio(), the gen of folio and corresponding lru size
>    may be updated, but the folio is not immediately moved to the
>    corresponding lru list. Therefore, there may be folios of different
>    generations on an LRU list.
> 4. In lru_gen_del_folio(), the generation to which the folio belongs is
>    found based on the generation information in folio->flags, and the
>    corresponding LRU size will be updated. Therefore, we need to update
>    the lru size correctly during reparenting, otherwise the lru size may
>    be updated incorrectly in lru_gen_del_folio().
> 
> Finally, this patch chose a compromise method, which is to splice the lru
> list in the child memcg to the lru list of the same generation in the
> parent memcg during reparenting. And in order to ensure that the parent
> memcg has the same generation, we need to increase the generations in the
> parent memcg to the MAX_NR_GENS before reparenting.
> 
> Of course, the same generation has different meanings in the parent and
> child memcg, this will cause confusion in the hot and cold information of
> folios. But other than that, this method is simple enough, the lru size
> is correct, and there is no need to consider some concurrency issues (such
> as lru_gen_del_folio()).
> 
> To prepare for the above work, this commit implements the specific
> functions, which will be used during reparenting.
> 
> Suggested-by: Harry Yoo <harry.yoo@xxxxxxxxxx>
> Suggested-by: Imran Khan <imran.f.khan@xxxxxxxxxx>
> Signed-off-by: Qi Zheng <zhengqi.arch@xxxxxxxxxxxxx>
> Acked-by: Harry Yoo <harry.yoo@xxxxxxxxxx>
> ---
> +/*
> + * Compared to traditional LRU, MGLRU faces the following challenges:
> + *
> + * 1. Each lruvec has between MIN_NR_GENS and MAX_NR_GENS generations, the
> + *    number of generations of the parent and child memcg may be different,
> + *    so we cannot simply transfer MGLRU folios in the child memcg to the
> + *    parent memcg as we did for traditional LRU folios.
> + * 2. The generation information is stored in folio->flags, but we cannot
> + *    traverse these folios while holding the lru lock, otherwise it may
> + *    cause softlockup.
> + * 3. In walk_update_folio(), the gen of folio and corresponding lru size
> + *    may be updated, but the folio is not immediately moved to the
> + *    corresponding lru list. Therefore, there may be folios of different
> + *    generations on an LRU list.
> + * 4. In lru_gen_del_folio(), the generation to which the folio belongs is
> + *    found based on the generation information in folio->flags, and the
> + *    corresponding LRU size will be updated. Therefore, we need to update
> + *    the lru size correctly during reparenting, otherwise the lru size may
> + *    be updated incorrectly in lru_gen_del_folio().
> + *
> + * Finally, we choose a compromise method, which is to splice the lru list in
> + * the child memcg to the lru list of the same generation in the parent memcg
> + * during reparenting.
> + *
> + * The same generation has different meanings in the parent and child memcg,
> + * so this compromise method will cause the LRU inversion problem. But as the
> + * system runs, this problem will be fixed automatically.
> + */
> +static void __lru_gen_reparent_memcg(struct lruvec *child_lruvec, struct lruvec *parent_lruvec,
> +				     int zone, int type)
> +{
> +	struct lru_gen_folio *child_lrugen, *parent_lrugen;
> +	enum lru_list lru = type * LRU_INACTIVE_FILE;
> +	int i;
> +
> +	child_lrugen = &child_lruvec->lrugen;
> +	parent_lrugen = &parent_lruvec->lrugen;
> +
> +	for (i = 0; i < get_nr_gens(child_lruvec, type); i++) {
> +		int gen = lru_gen_from_seq(child_lrugen->max_seq - i);
> +		long nr_pages = child_lrugen->nr_pages[gen][type][zone];
> +		int child_lru_active = lru_gen_is_active(child_lruvec, gen) ? LRU_ACTIVE : 0;
> +		int parent_lru_active = lru_gen_is_active(parent_lruvec, gen) ? LRU_ACTIVE : 0;

Not a correctness thing, but...

> +		/* Assuming that child pages are colder than parent pages */
> +		list_splice_init(&child_lrugen->folios[gen][type][zone],
> +				 &parent_lrugen->folios[gen][type][zone]);

I think the other end (tail) is where cold pages go in MGLRU just like
in the traditional LRU, since  lru_to_folio(head) returns the tail folio?

> +		WRITE_ONCE(child_lrugen->nr_pages[gen][type][zone], 0);
> +		WRITE_ONCE(parent_lrugen->nr_pages[gen][type][zone],
> +			   parent_lrugen->nr_pages[gen][type][zone] + nr_pages);
> +
> +		if (lru_gen_is_active(child_lruvec, gen) != lru_gen_is_active(parent_lruvec, gen)) {
> +			__update_lru_size(child_lruvec, lru + child_lru_active, zone, -nr_pages);
> +			__update_lru_size(parent_lruvec, lru + parent_lru_active, zone, nr_pages);
> +		}
> +	}
> +}

-- 
Cheers,
Harry / Hyeonggon