All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Barry Song (Xiaomi)" <baohua@kernel.org>,
	akpm@linux-foundation.org, linux-mm@kvack.org
Cc: axelrasmussen@google.com, baolin.wang@linux.alibaba.com,
	baoquan.he@linux.dev, hannes@cmpxchg.org, hui.zhu@linux.dev,
	kasong@tencent.com, kunwu.chan@gmail.com, liam@infradead.org,
	lianux.mm@gmail.com, liuxiang.277@bytedance.com,
	lyugaofei@xiaomi.com, mhocko@kernel.org, mhocko@suse.com,
	qi.zheng@linux.dev, ridong.chen@linux.dev, rppt@kernel.org,
	ryncsn@gmail.com, shakeel.butt@linux.dev, surenb@google.com,
	wangzicheng@honor.com, weixugc@google.com, yuanchu@google.com,
	zhangbo56@xiaomi.com, zhuhui@kylinos.cn,
	sidchintamaneni@gmail.com
Subject: Re: [PATCH v9 11/16] mm/mglru: Run aging when one type is drained
Date: Sat, 14 Nov 2026 20:50:22 +0000	[thread overview]
Message-ID: <sashiko-outbox-215014@kernel.org> (raw)
In-Reply-To: <20261114200803.23129-12-baohua@kernel.org>

Thank you for your contribution! Sashiko AI review found 2 potential
issues to consider:
- [Medium] mm/mglru: scan_folios() scans seq below min_seq at
  DEF_PRIORITY
- [Low] mm/mglru: missed eviction retry in try_to_shrink_lruvec() on
  concurrent aging
--

commit 230d3708cf744410ec1f04bfd86215ddf2b3c664
Author: Barry Song (Xiaomi) <baohua@kernel.org>

mm/mglru: Run aging when one type is drained

This commit moves MGLRU aging after eviction in try_to_shrink_lruvec() and
triggers aging once per invocation when an evictable type is drained.

> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 1450542d709c3..6d942f192e63a 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
[ ... ]
> @@ -5226,22 +5235,17 @@ static bool try_to_shrink_lruvec(struct lruvec *lruvec, struct scan_control *sc)
>  	lru_gen_prepare_scan(lruvec, sc, memcg, swappiness, nr);
>  
>  	while (nr[LRU_GEN_ANON] > 0 || nr[LRU_GEN_FILE] > 0) {
> +		bool drained = false, do_drained_age;
>  		DEFINE_MAX_SEQ(lruvec);
> +		unsigned long new_seq;
> +		long scanned;
>  
>  		if (mem_cgroup_below_min(sc->target_mem_cgroup, memcg)) {
>  			need_rotate = true;
>  			break;
>  		}
>  
> -		if (should_run_aging(lruvec, max_seq, sc, swappiness)) {
> -			trace_mm_mglru_aging(lruvec, sc, swappiness);
> -			if (try_to_inc_max_seq(lruvec, max_seq, swappiness, false))
> -				need_rotate = true;
> -			should_age = true;
> -		}
> -
> -		if (!evict_folio_lists(nr, lruvec, sc, swappiness, MIN_LRU_BATCH))
> -			break;
> +		scanned = evict_folio_lists(nr, lruvec, sc, swappiness, MIN_LRU_BATCH, &drained);

[Severity: Medium]
Can calling evict_folio_lists() before should_run_aging() cause
scan_folios() to scan a generation below min_seq[type] at DEF_PRIORITY?

Previously, should_run_aging() ran first and incremented max_seq at
DEF_PRIORITY whenever a type had only MIN_NR_GENS generations
(min_seq[type] == max_seq - 1).  With eviction moved ahead of aging,
evict_folio_lists() -> evict_folios() -> scan_folios() now runs while
min_seq[type] == max_seq - 1:

mm/vmscan.c:scan_folios() {
    ...
	if (sc->priority == DEF_PRIORITY)
		seq = lrugen->max_seq - MIN_NR_GENS;
	else if (sc->priority > AGING_PRIORITY)
		seq = lrugen->max_seq - 1;
	else
		seq = lrugen->max_seq;

	seq = lruvec_populated_min_seq(lruvec, type, sc->reclaim_idx + 1, seq);
    ...
}

Because seq is max_seq - 2 (< min_seq[type]), the while (min_seq < max_seq)
loop in lruvec_populated_min_seq() does not execute and returns max_seq - 2.
scan_folios() then scans the out-of-window slot
lrugen->folios[lru_gen_from_seq(max_seq - 2)][type][zone_idx], prematurely
isolating or promoting folios parked in that slot by memcg reparenting to
await future aging, and re-adding rejected folios via move_folios_to_lru()
at scanned_seq + 1 == min_seq[type] instead of promoting them above
min_seq[type].

>  
>  		if (should_abort_scan(lruvec, sc))
>  			break;
> @@ -5253,6 +5257,27 @@ static bool try_to_shrink_lruvec(struct lruvec *lruvec, struct scan_control *sc)
>  		if (root_reclaim(sc) && should_age)
>  			break;
>  
> +		/*
> +		 * Allow drained aging only once per invocation and skip it if
> +		 * max_seq advanced concurrently during eviction
> +		 */
> +		new_seq = READ_ONCE(lruvec->lrugen.max_seq);
> +		do_drained_age = drained && allow_drained_age && max_seq == new_seq;
> +		allow_drained_age &= !do_drained_age;
> +		if (do_drained_age || should_run_aging(lruvec, new_seq, sc, swappiness)) {
> +			trace_mm_mglru_aging(lruvec, sc, swappiness);
> +			if (try_to_inc_max_seq(lruvec, new_seq, swappiness, false))
> +				need_rotate = true;
> +			should_age = true;
> +		}
> +
> +		if (!scanned) {
> +			/* Retry once if aging advanced max_seq */
> +			if (retried || new_seq == READ_ONCE(lruvec->lrugen.max_seq))
> +				break;
> +			retried = true;
> +		}

[Severity: Low]
Should the retry check compare READ_ONCE(lruvec->lrugen.max_seq) against
max_seq instead of new_seq?

CPU0                              CPU1
try_to_shrink_lruvec()
  max_seq = lrugen.max_seq
  evict_folio_lists() -> 0
                                  try_to_inc_max_seq()
                                    inc_max_seq()
                                      lrugen.max_seq++
  new_seq = lrugen.max_seq
  max_seq == new_seq is false
  /* aging skipped */
  new_seq == lrugen.max_seq       <-- breaks without retrying

When a concurrent reclaimer advances max_seq after scan_folios() finds no
folios and before new_seq is read, do_drained_age is skipped because
max_seq != new_seq and should_run_aging() is evaluated against the already
incremented new_seq.  Comparing lrugen.max_seq against new_seq then sees no
change and breaks out of try_to_shrink_lruvec() without retrying eviction
on the newly aged generation.

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


  reply	other threads:[~2026-11-14 20:50 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-14 20:07 [PATCH v9 00/16] mm: mglru: fix swappiness behavior Barry Song (Xiaomi)
2026-11-14 20:07 ` [PATCH v9 01/16] mm/mglru: report evictable sizes per type Barry Song (Xiaomi)
2026-11-14 20:07 ` [PATCH v9 02/16] mm/mglru: extract lruvec_populated_min_seq() helper Barry Song (Xiaomi)
2026-11-14 20:07 ` [PATCH v9 03/16] mm/mglru: reclaim from the oldest populated gen Barry Song (Xiaomi)
2026-11-14 20:07 ` [PATCH v9 04/16] mm/mglru: lift the forced protection of reclaimer Barry Song (Xiaomi)
2026-11-14 20:07 ` [PATCH v9 05/16] mm/mglru: skip zones above reclaim_idx instead of rotating them Barry Song (Xiaomi)
2026-11-14 20:07 ` [PATCH v9 06/16] mm/mglru: return for unavailable anon reclaim earlier Barry Song (Xiaomi)
2026-11-14 20:07 ` [PATCH v9 07/16] mm/mglru: balance anon and file scan budget by refault rate Barry Song (Xiaomi)
2026-11-14 20:07 ` [PATCH v9 08/16] mm/mglru: lift youngest gen protection for higher priority Barry Song (Xiaomi)
2026-11-14 20:07 ` [PATCH v9 09/16] mm/mglru: Avoid placing rejected folios below populated gen Barry Song (Xiaomi)
2026-11-14 20:07 ` [PATCH v9 10/16] mm/mglru: Run aging when pages are rare outside the youngest gen Barry Song (Xiaomi)
2026-11-14 20:07 ` [PATCH v9 11/16] mm/mglru: Run aging when one type is drained Barry Song (Xiaomi)
2026-11-14 20:50   ` sashiko-bot [this message]
2026-11-14 20:07 ` [PATCH v9 12/16] mm/mglru: Restrict eviction accounting to eligible zones Barry Song (Xiaomi)
2026-11-14 20:08 ` [PATCH v9 13/16] mm/mglru: Reduce LRU lock contention by shrinking folio batches in inc_min_seq Barry Song (Xiaomi)
2026-11-14 20:08 ` [PATCH v9 14/16] mm/mglru: Avoid prolonged anon reclaim with swappiness=200 Barry Song (Xiaomi)
2026-11-14 20:08 ` [PATCH v9 15/16] mm/mglru: Make swappiness=1 file reclaim more aggressive Barry Song (Xiaomi)
2026-11-14 20:08 ` [PATCH v9 16/16] mm/mglru: Avoid scan anon while swapcache is low for GFP_NOIO allocation Barry Song (Xiaomi)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-215014@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=baoquan.he@linux.dev \
    --cc=hannes@cmpxchg.org \
    --cc=hui.zhu@linux.dev \
    --cc=kasong@tencent.com \
    --cc=kunwu.chan@gmail.com \
    --cc=liam@infradead.org \
    --cc=lianux.mm@gmail.com \
    --cc=linux-mm@kvack.org \
    --cc=liuxiang.277@bytedance.com \
    --cc=lyugaofei@xiaomi.com \
    --cc=mhocko@kernel.org \
    --cc=mhocko@suse.com \
    --cc=qi.zheng@linux.dev \
    --cc=ridong.chen@linux.dev \
    --cc=rppt@kernel.org \
    --cc=ryncsn@gmail.com \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=shakeel.butt@linux.dev \
    --cc=sidchintamaneni@gmail.com \
    --cc=surenb@google.com \
    --cc=wangzicheng@honor.com \
    --cc=weixugc@google.com \
    --cc=yuanchu@google.com \
    --cc=zhangbo56@xiaomi.com \
    --cc=zhuhui@kylinos.cn \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.