The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Baolin Wang <baolin.wang@linux.alibaba.com>
To: Hui Zhu <hui.zhu@linux.dev>,
	Andrew Morton <akpm@linux-foundation.org>,
	Kairui Song <kasong@tencent.com>, Qi Zheng <qi.zheng@linux.dev>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Barry Song <baohua@kernel.org>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	David Hildenbrand <david@kernel.org>,
	Michal Hocko <mhocko@kernel.org>,
	Lorenzo Stoakes <ljs@kernel.org>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org
Cc: Hui Zhu <zhuhui@kylinos.cn>
Subject: Re: [PATCH mm-unstable v2 2/2] mm/vmscan: apply too_many_isolated() throttling to MGLRU eviction
Date: Tue, 18 Aug 2026 11:36:14 +0800	[thread overview]
Message-ID: <e5c15b42-55e9-4912-9000-cd720a44b57b@linux.alibaba.com> (raw)
In-Reply-To: <858e2e0ae536bbe185267472d3c84a5684937131.1786950138.git.zhuhui@kylinos.cn>



On 8/17/26 3:11 PM, Hui Zhu wrote:
> From: Hui Zhu <zhuhui@kylinos.cn>
> 
> The legacy path throttles direct reclaim in shrink_inactive_list()
> when too many isolated folios pile up, but MGLRU's evict_folios()
> isolates folios without this check, which can lead to unnecessary
> swapping, thrashing and OOM.
> 
> With the NR_ISOLATED counters now updated in evict_folios(), extract
> the throttling loop from shrink_inactive_list() into
> throttle_isolated() and reuse it in evict_folios(). The type to
> isolate is predicted with get_type_to_scan() since it is unknown
> until isolation.
> 
> If a fatal signal is pending, fake reclaim progress the same way the
> legacy path does, so the dying task exits reclaim quickly instead of
> being held in the throttle.
> 
> Signed-off-by: Hui Zhu <zhuhui@kylinos.cn>
> ---
>   mm/vmscan.c | 67 ++++++++++++++++++++++++++++++++++++++++++++---------
>   1 file changed, 56 insertions(+), 11 deletions(-)
> 
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index fdc45d7d8fba..886a53f563ab 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -1819,7 +1819,7 @@ bool folio_isolate_lru(struct folio *folio)
>    * the LRU list will go small and be scanned faster than necessary, leading to
>    * unnecessary swapping, thrashing and OOM.
>    */
> -static bool too_many_isolated(struct pglist_data *pgdat, int file,
> +static bool too_many_isolated(struct pglist_data *pgdat, bool file,
>   		struct scan_control *sc)
>   {
>   	unsigned long inactive, isolated;
> @@ -1856,6 +1856,37 @@ static bool too_many_isolated(struct pglist_data *pgdat, int file,
>   	return too_many;
>   }
>   
> +/*
> + * Throttle reclaim if too many isolated folios are piling up. If this makes
> + * no progress, the caller is probably looping on unevictable folios, so give
> + * up. Returns false to tell the caller to stop reclaiming, and sets @fatal
> + * if the task received a fatal signal while waiting, so that the caller can
> + * bail out faster.
> + */
> +static bool throttle_isolated(struct pglist_data *pgdat, bool file,
> +			      struct scan_control *sc, bool *fatal)
> +{
> +	bool stalled = false;
> +
> +	*fatal = false;
> +	while (unlikely(too_many_isolated(pgdat, file, sc))) {
> +		if (stalled)
> +			return false;
> +
> +		/* wait a bit for the reclaimer. */
> +		stalled = true;
> +		reclaim_throttle(pgdat, VMSCAN_THROTTLE_ISOLATED);
> +
> +		/* We are about to die and free our memory. Return now. */
> +		if (fatal_signal_pending(current)) {
> +			*fatal = true;
> +			return false;
> +		}
> +	}
> +
> +	return true;

Returning ‘true’ or 'false' looks confusing to me, maybe use a readable 
variable 'is_throttled'?

> +}
> +
>   /*
>    * move_folios_to_lru() moves folios from private @list to appropriate LRU list.
>    *
> @@ -1992,19 +2023,14 @@ static unsigned long shrink_inactive_list(unsigned long nr_to_scan,
>   	bool file = is_file_lru(lru);
>   	enum node_stat_item item;
>   	struct pglist_data *pgdat = lruvec_pgdat(lruvec);
> -	bool stalled = false;
> -
> -	while (unlikely(too_many_isolated(pgdat, file, sc))) {
> -		if (stalled)
> -			return 0;
> -
> -		/* wait a bit for the reclaimer. */
> -		stalled = true;
> -		reclaim_throttle(pgdat, VMSCAN_THROTTLE_ISOLATED);
> +	bool fatal;
>   
> +	if (!throttle_isolated(pgdat, file, sc, &fatal)) {
>   		/* We are about to die and free our memory. Return now. */
> -		if (fatal_signal_pending(current))
> +		if (fatal)
>   			return SWAP_CLUSTER_MAX;
> +
> +		return 0;
>   	}
>   
>   	lru_add_drain();
> @@ -4883,6 +4909,25 @@ static int evict_folios(unsigned long nr_to_scan, struct lruvec *lruvec,
>   	bool skip_retry = false;
>   	struct mem_cgroup *memcg = lruvec_memcg(lruvec);
>   	struct pglist_data *pgdat = lruvec_pgdat(lruvec);
> +	bool fatal;
> +
> +	/*
> +	 * The type to isolate is unknown until isolation, so predict it for
> +	 * the throttling check. isolate_folios() may still fall back to the
> +	 * other type, which is fine for this heuristic.
> +	 */
> +	type = get_type_to_scan(lruvec, swappiness);

Perhaps we could use 'for_each_evictable_type(i, swappiness)' to check 
each type's isolation?

> +	if (!throttle_isolated(pgdat, type, sc, &fatal)) {
> +		/*
> +		 * We are about to die and free our memory. Like the legacy
> +		 * path, pretend some pages were reclaimed so reclaim unwinds
> +		 * quickly instead of looping back into the throttle.
> +		 */
> +		if (fatal)
> +			sc->nr_reclaimed += SWAP_CLUSTER_MAX;
> +
> +		return 0;
> +	}
>   
>   	lruvec_lock_irq(lruvec);
>   


      reply	other threads:[~2026-08-18  3:36 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-17  7:11 [PATCH mm-unstable v2 0/2] mm/vmscan: fix NR_ISOLATED accounting and throttling for MGLRU Hui Zhu
2026-08-17  7:11 ` [PATCH mm-unstable v2 1/2] mm/vmscan: fix missing NR_ISOLATED counter update in MGLRU reclaim path Hui Zhu
2026-08-18  3:19   ` Baolin Wang
2026-08-17  7:11 ` [PATCH mm-unstable v2 2/2] mm/vmscan: apply too_many_isolated() throttling to MGLRU eviction Hui Zhu
2026-08-18  3:36   ` Baolin Wang [this message]

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=e5c15b42-55e9-4912-9000-cd720a44b57b@linux.alibaba.com \
    --to=baolin.wang@linux.alibaba.com \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=baohua@kernel.org \
    --cc=david@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=hui.zhu@linux.dev \
    --cc=kasong@tencent.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=ljs@kernel.org \
    --cc=mhocko@kernel.org \
    --cc=qi.zheng@linux.dev \
    --cc=shakeel.butt@linux.dev \
    --cc=weixugc@google.com \
    --cc=yuanchu@google.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox