Re: [RFC PATCH v5 08/14] mm/mglru: lift youngest gen protection for higher priority

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] mm/mglru: scan_folios() scans expired gen < min_seq at DEF_PRIORITY
--

commit 1329290ce5f86b7de9b77d6b22e4b265f16348ae
Author: Kairui Song <kasong@tencent.com>

mm/mglru: lift youngest gen protection for higher priority

This commit adjusts scan_folios() in mm/vmscan.c to choose the target
generation sequence number based on reclaim priority rather than using
lrugen->min_seq[type] at default priority. It aims to protect younger
generations at default priority while allowing higher-priority reclaim to
scan newer generations step by step.

> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index fed39b0422e01..d1e14001f9346 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -4930,12 +4930,14 @@ static int scan_folios(unsigned long nr_to_scan, struct lruvec *lruvec,
>  	VM_WARN_ON_ONCE(!list_empty(list));
>  
>  	/*
> -	 * Respect the gen hotness distribution at low priority to avoid
> -	 * aging and scan cost, but prefer to satisfy the reclaimers request
> -	 * when under pressure to respect swappiness more and reduce IO cost.
> +	 * Respect hotness at default priority, and only reach into the
> +	 * newest generation when under severe pressure, so hot folios are
> +	 * not evicted as soon as priority is raised.
>  	 */
>  	if (sc->priority == DEF_PRIORITY)
> -		seq = lrugen->min_seq[type];
> +		seq = lrugen->max_seq - MIN_NR_GENS;
> +	else if (sc->priority > DEF_PRIORITY / 2)
> +		seq = lrugen->max_seq - 1;
>  	else
>  		seq = lrugen->max_seq;
>  

[Severity: Medium]
Can this cause scan_folios() in mm/vmscan.c to scan an already-evicted
generation when a type only has the minimum number of generations left?

In try_to_shrink_lruvec() -> evict_folio_lists() -> evict_folios() ->
scan_folios() at default priority, when get_nr_gens(lruvec, type) is at the
minimum (2 generations), lrugen->min_seq[type] is lrugen->max_seq - 1, while
scan_folios() sets seq to lrugen->max_seq - 2 and passes it as max_seq to
lruvec_populated_min_seq():

mm/vmscan.c:scan_folios() {
	if (sc->priority == DEF_PRIORITY)
		seq = lrugen->max_seq - MIN_NR_GENS;
	...
	seq = lruvec_populated_min_seq(lruvec, type, sc->reclaim_idx + 1, seq);
	gen = lru_gen_from_seq(seq);
}

In lruvec_populated_min_seq(), because min_seq (lrugen->max_seq - 1) is
greater than max_seq (lrugen->max_seq - 2), the while loop is skipped and
max_seq is returned directly:

mm/vmscan.c:lruvec_populated_min_seq() {
	min_seq = READ_ONCE(lrugen->min_seq[type]);
	while (min_seq <= max_seq) {
		gen = lru_gen_from_seq(min_seq);
		for (zone = 0; zone < zone_limit; zone++) {
			if (!list_empty(&lrugen->folios[gen][type][zone]))
				return min_seq;
		}
		min_seq++;
	}

	return max_seq;
}

When scan_folios() previously scanned younger generations (lrugen->max_seq - 1
or lrugen->max_seq) at elevated priority while get_nr_gens(lruvec, type) had
fewer than the maximum number of generations, sort_folio() can move folios
with a stale folio_lru_gen() value (such as after __lru_gen_reparent_memcg()
or when inc_min_seq() skipped draining old_gen) into that expired
lrugen->folios[gen][type][zone] list:

mm/vmscan.c:sort_folio() {
	/* promoted, or moved due to reparenting. */
	if (gen != min_gen) {
		list_move(&folio->lru, &lrugen->folios[gen][type][zone]);
		return true;
	}
}

A subsequent default-priority call to scan_folios() will then visit that
expired generation (< lrugen->min_seq[type]) and corrupt active/inactive size
accounting.

In addition, in lru_gen_seq_write() -> run_cmd() -> run_eviction(), debugfs
eviction runs at default priority. If a user requests evicting up to
lrugen->max_seq - 3 when four generations exist and one type has already
emptied lrugen->max_seq - 3 while the other type still has min_seq at
lrugen->max_seq - 3, wouldn't setting seq to lrugen->max_seq - 2 in
scan_folios() evict folios from generation lrugen->max_seq - 2, exceeding the
requested seq bound?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261022220203.91911-1-baohua@kernel.org?part=8