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
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, linux-mm@kvack.org,
	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,
	"Kunwu Chan" <chentao@kylinos.cn>
Subject: Re: [PATCH v7 16/16] mm/mglru: Avoid scan anon while swapcache is low for GFP_NOIO allocation
Date: Thu, 12 Nov 2026 05:01:15 +0000	[thread overview]
Message-ID: <sashiko-outbox-210424@kernel.org> (raw)
In-Reply-To: <20261111232603.9934-17-baohua@kernel.org>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] mm/mglru: stalled aging in try_to_shrink_lruvec() under
  GFP_NOIO
--

commit c2e07c75b5549aa295c630747e1cecd7625269f0
Author: Bo Zhang <zhangbo56@xiaomi.com>

mm/mglru: Avoid scan anon while swapcache is low for GFP_NOIO allocation

This commit skips anonymous folio scanning in MGLRU when GFP_NOIO is set
and swapcache is low by checking can_reclaim_anon_pages() in
lruvec_evictable_size().

> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index f36e9a379b62a..4fdbf0c2dcde0 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
[ ... ]
> @@ -4213,6 +4206,8 @@ static void lruvec_evictable_size(struct lruvec *lruvec, struct scan_control *sc
>  	int type;
>  	unsigned long seq;
>  	struct lru_gen_folio *lrugen = &lruvec->lrugen;
> +	struct mem_cgroup *memcg = lruvec_memcg(lruvec);
> +	int nid = lruvec_pgdat(lruvec)->node_id;
>  	DEFINE_MAX_SEQ(lruvec);
>  	DEFINE_MIN_SEQ(lruvec);
>  
> @@ -4220,6 +4215,8 @@ static void lruvec_evictable_size(struct lruvec *lruvec, struct scan_control *sc
>  	nr[LRU_GEN_FILE] = 0;
>  
>  	for_each_evictable_type(type, swappiness) {
> +		if (type == LRU_GEN_ANON && !can_reclaim_anon_pages(memcg, nid, sc))
> +			continue;
>  		for (seq = min_seq[type]; seq <= max_seq; seq++)
>  			nr[type] += lruvec_gen_size(lrugen, type, seq, sc->reclaim_idx + 1);
>  	}

[Severity: Medium]
Can zeroing nr[LRU_GEN_ANON] here while swappiness remains non-zero stall
MGLRU aging during GFP_NOIO reclaim?

When swap space is available and NUMA demotion is not, get_swappiness()
stays in 1..MAX_SWAPPINESS even when can_reclaim_anon_pages() returns
false. Because nr[LRU_GEN_ANON] is 0, evict_folio_lists() only scans file
generations, so min_seq[LRU_GEN_ANON] stays at max_seq - 3 and
try_to_inc_min_seq() clamps min_seq[LRU_GEN_FILE] to max_seq - MIN_NR_GENS:

mm/vmscan.c:try_to_inc_min_seq() {
	...
	if (swappiness && swappiness <= MAX_SWAPPINESS) {
		unsigned long seq = lrugen->max_seq - MIN_NR_GENS;

		if (min_seq[LRU_GEN_ANON] > seq && min_seq[LRU_GEN_FILE] < seq)
			min_seq[LRU_GEN_ANON] = seq;
		else if (min_seq[LRU_GEN_FILE] > seq && min_seq[LRU_GEN_ANON] < seq)
			min_seq[LRU_GEN_FILE] = seq;
	}
}

Once populatable file generations are drained, evict_folio_lists() returns
0 and try_to_shrink_lruvec() breaks out of the loop before setting
no_populatable, while should_run_aging() sees evictable_min_seq() at
min_seq[LRU_GEN_ANON] (max_seq - 3) and lru_gen_imbalanced() still counts
unreclaimable anon pages in old[LRU_GEN_ANON]. As a result, reclaim fails
to age from DEF_PRIORITY down to DEF_PRIORITY / 2 + 1 and then directly
evicts the youngest file generation (max_seq) without page-table aging or
tier protection.

Should get_swappiness() return 0 when !can_reclaim_anon_pages() instead, so
swappiness is 0 consistently across try_to_shrink_lruvec(),
try_to_inc_min_seq(), should_run_aging(), and lru_gen_imbalanced()?

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


  reply	other threads:[~2026-11-12  5:01 UTC|newest]

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

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-210424@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=chentao@kylinos.cn \
    --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.