All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@linux-foundation.org>
To: kasong@tencent.com
Cc: Kairui Song via B4 Relay <devnull+kasong.tencent.com@kernel.org>,
	linux-mm@kvack.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>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Lorenzo Stoakes <ljs@kernel.org>, Barry Song <baohua@kernel.org>,
	David Stevens <stevensd@google.com>,
	Chen Ridong <chenridong@huaweicloud.com>,
	Leno Hou <lenohou@gmail.com>, Yafang Shao <laoar.shao@gmail.com>,
	Yu Zhao <yuzhao@google.com>, Zicheng Wang <wangzicheng@honor.com>,
	Baolin Wang <baolin.wang@linux.alibaba.com>,
	Kalesh Singh <kaleshsingh@google.com>,
	Suren Baghdasaryan <surenb@google.com>,
	Chris Li <chrisl@kernel.org>, Vernon Yang <vernon2gm@gmail.com>,
	linux-kernel@vger.kernel.org, Kairui Song <ryncsn@gmail.com>,
	Qi Zheng <qi.zheng@linux.dev>
Subject: Re: [PATCH v7 00/15] mm/mglru: improve reclaim loop and dirty folio handling
Date: Mon, 27 Apr 2026 11:22:25 -0700	[thread overview]
Message-ID: <20260427112225.3f752a385f58bd7dfddfaa25@linux-foundation.org> (raw)
In-Reply-To: <20260428-mglru-reclaim-v7-0-02fabb92dc43@tencent.com>

On Tue, 28 Apr 2026 02:06:51 +0800 Kairui Song via B4 Relay <devnull+kasong.tencent.com@kernel.org> wrote:

> From: Kairui Song <kasong@tencent.com>
> 
> This series cleans up and slightly improves MGLRU's reclaim loop and
> dirty writeback handling. As a result, we can see an up to ~30% increase
> in some workloads like MongoDB with YCSB and a huge decrease in file
> refault, no swap involved. Other common benchmarks have no regression,
> and LOC is reduced, with less unexpected OOM, too.

Thanks, I've updated mm.git's mm-new branch to this version.

> Changes in v7:
> - Fix swappiness not being effective with a standalone fix patch
>   from Barry Song. It's OK to be a standalone fix since that is not a
>   major bug but an unexpected behavior change, and shouldn't effect any
>   bisecting. I slightly adjusted the commit message as the subjcect is too
>   long and getting truncated for mail:
>   https://lore.kernel.org/linux-mm/20260425205759.1701-1-baohua@kernel.org/
> - Remove the min limit for calculating nr_to_scan:
>   https://lore.kernel.org/linux-mm/aet1hd9DfRH4aSOO@KASONG-MC4/
>   Instead just revert to V1:
>   https://sashiko.dev/#/message/20260318-mglru-reclaim-v1-3-2c46f9eb0508%40tencent.com
>   Everyone was fine with that, the min limit in later version was
>   introduced to cover sashiko's review on V1, but now think again, that's
>   actually not a bug and instead could be beneficial. This min
>   check doesn't always make sense and there isn't any practical issue observed.
> - Retest still looking very good in every case.

Here's how v7 altered mm.git.   (Looks small - did I mess this up?)


--- a/mm/vmscan.c~b
+++ a/mm/vmscan.c
@@ -4788,8 +4788,13 @@ static int isolate_folios(unsigned long
 			*isolate_scanned = scanned;
 			break;
 		}
-
-		type = !type;
+		/*
+		 * If scanned > 0 and isolated == 0, avoid falling back to the
+		 * other type, as this type remains sufficient. Falling back
+		 * too readily can disrupt the positive_ctrl_err() bias.
+		 */
+		if (!scanned)
+			type = !type;
 	}
 
 	return total_scanned;
@@ -4909,18 +4914,14 @@ static long get_nr_to_scan(struct lruvec
 	unsigned long nr_to_scan, evictable;
 
 	evictable = lruvec_evictable_size(lruvec, swappiness);
-	nr_to_scan = evictable;
 
 	/* try to scrape all its memory if this memcg was deleted */
 	if (!mem_cgroup_online(memcg))
-		return nr_to_scan;
+		return evictable;
 
-	nr_to_scan = apply_proportional_protection(memcg, sc, nr_to_scan);
+	nr_to_scan = apply_proportional_protection(memcg, sc, evictable);
 	nr_to_scan >>= sc->priority;
 
-	if (!nr_to_scan && sc->priority < DEF_PRIORITY)
-		nr_to_scan = min(evictable, SWAP_CLUSTER_MAX);
-
 	return nr_to_scan;
 }
 
_



  parent reply	other threads:[~2026-04-27 18:22 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-27 18:06 [PATCH v7 00/15] mm/mglru: improve reclaim loop and dirty folio handling Kairui Song
2026-04-27 18:06 ` Kairui Song via B4 Relay
2026-04-27 18:06 ` [PATCH v7 01/15] mm/mglru: consolidate common code for retrieving evictable size Kairui Song
2026-04-27 18:06   ` Kairui Song via B4 Relay
2026-04-27 18:06 ` [PATCH v7 02/15] mm/mglru: rename variables related to aging and rotation Kairui Song
2026-04-27 18:06   ` Kairui Song via B4 Relay
2026-04-27 18:06 ` [PATCH v7 03/15] mm/mglru: relocate the LRU scan batch limit to callers Kairui Song
2026-04-27 18:06   ` Kairui Song via B4 Relay
2026-04-27 18:06 ` [PATCH v7 04/15] mm/mglru: restructure the reclaim loop Kairui Song
2026-04-27 18:06   ` Kairui Song via B4 Relay
2026-04-27 18:06 ` [PATCH v7 05/15] mm/mglru: scan and count the exact number of folios Kairui Song
2026-04-27 18:06   ` Kairui Song via B4 Relay
2026-04-27 18:06 ` [PATCH v7 06/15] mm/mglru: avoid reclaim type fall back when isolation makes no progress Kairui Song
2026-04-27 18:06   ` Kairui Song via B4 Relay
2026-04-28  4:18   ` Kairui Song
2026-04-27 18:06 ` [PATCH v7 07/15] mm/mglru: use a smaller batch for reclaim Kairui Song
2026-04-27 18:06   ` Kairui Song via B4 Relay
2026-04-27 18:06 ` [PATCH v7 08/15] mm/mglru: don't abort scan immediately right after aging Kairui Song
2026-04-27 18:06   ` Kairui Song via B4 Relay
2026-04-27 18:07 ` [PATCH v7 09/15] mm/mglru: remove redundant swap constrained check upon isolation Kairui Song
2026-04-27 18:07   ` Kairui Song via B4 Relay
2026-04-27 18:07 ` [PATCH v7 10/15] mm/mglru: use the common routine for dirty/writeback reactivation Kairui Song
2026-04-27 18:07   ` Kairui Song via B4 Relay
2026-04-27 18:07 ` [PATCH v7 11/15] mm/mglru: simplify and improve dirty writeback handling Kairui Song
2026-04-27 18:07   ` Kairui Song via B4 Relay
2026-04-27 18:07 ` [PATCH v7 12/15] mm/mglru: remove no longer used reclaim argument for folio protection Kairui Song
2026-04-27 18:07   ` Kairui Song via B4 Relay
2026-04-27 18:07 ` [PATCH v7 13/15] mm/vmscan: remove sc->file_taken Kairui Song
2026-04-27 18:07   ` Kairui Song via B4 Relay
2026-04-27 18:07 ` [PATCH v7 14/15] mm/vmscan: remove sc->unqueued_dirty Kairui Song
2026-04-27 18:07   ` Kairui Song via B4 Relay
2026-04-27 18:07 ` [PATCH v7 15/15] mm/vmscan: unify writeback reclaim statistic and throttling Kairui Song
2026-04-27 18:07   ` Kairui Song via B4 Relay
2026-04-27 18:22 ` Andrew Morton [this message]
2026-05-11 18:51 ` [PATCH v7 00/15] mm/mglru: improve reclaim loop and dirty folio handling Shakeel Butt
2026-05-12  5:08   ` Kairui Song
2026-05-12  5:56     ` Shakeel Butt
2026-05-14 18:50 ` Kairui 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=20260427112225.3f752a385f58bd7dfddfaa25@linux-foundation.org \
    --to=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=chenridong@huaweicloud.com \
    --cc=chrisl@kernel.org \
    --cc=david@kernel.org \
    --cc=devnull+kasong.tencent.com@kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=kaleshsingh@google.com \
    --cc=kasong@tencent.com \
    --cc=laoar.shao@gmail.com \
    --cc=lenohou@gmail.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=ryncsn@gmail.com \
    --cc=shakeel.butt@linux.dev \
    --cc=stevensd@google.com \
    --cc=surenb@google.com \
    --cc=vernon2gm@gmail.com \
    --cc=wangzicheng@honor.com \
    --cc=weixugc@google.com \
    --cc=yuanchu@google.com \
    --cc=yuzhao@google.com \
    /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.