From nobody Thu Apr 2 17:42:02 2026 Received: from SHSQR01.spreadtrum.com (unknown [222.66.158.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id AC41E1E487 for ; Wed, 18 Mar 2026 01:16:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=222.66.158.135 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773796616; cv=none; b=DONYhBuOxwFC9U4bS9CVSdDuRZ2X5yUrXfFsfGYe43IyVova9BLe6dVUqCOAhGGlIX0xag7Ewg03ZkhNcYyXB2z8LF8noSnRTk6akVDN8TOQiaFtfVh1SQn6GX5Kst8pJnhzivIHzb/2kBusl/jK8g92uaneL5XwKRGBSP6n02Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773796616; c=relaxed/simple; bh=CDDJjdm9puv/dHdpCli07dv1oaOwcxwn+NAiCi4/XUs=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=XYL6bx6e/Zl/v5WsGeIfV1P8IW+z9JwS8kyKHirf3GVqHQjSVoi1cv7uB1rV2N8bPyw5REh6xEDrjrbbCAorcMraHaXcXfH2Y3QfZn5IkwucoIbSab7uENOh2FrZ5GF7NDFScYMm1KT0hTvao+wd9ns67lM9m9fsJBESxeRTauI= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=unisoc.com; spf=pass smtp.mailfrom=unisoc.com; dkim=pass (2048-bit key) header.d=unisoc.com header.i=@unisoc.com header.b=F29JCSOQ; arc=none smtp.client-ip=222.66.158.135 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=unisoc.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=unisoc.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=unisoc.com header.i=@unisoc.com header.b="F29JCSOQ" Received: from dlp.unisoc.com ([10.29.3.86]) by SHSQR01.spreadtrum.com with ESMTP id 62I1GBap066683; Wed, 18 Mar 2026 09:16:11 +0800 (+08) (envelope-from zhaoyang.huang@unisoc.com) Received: from SHDLP.spreadtrum.com (BJMBX01.spreadtrum.com [10.0.64.7]) by dlp.unisoc.com (SkyGuard) with ESMTPS id 4fb9pn3vGKz2P3l1g; Wed, 18 Mar 2026 09:14:41 +0800 (CST) Received: from bj03382pcu03.spreadtrum.com (10.0.73.40) by BJMBX01.spreadtrum.com (10.0.64.7) with Microsoft SMTP Server (TLS) id 15.0.1497.48; Wed, 18 Mar 2026 09:16:07 +0800 From: "zhaoyang.huang" To: Andrew Morton , Michal Hocko , "T . J . Mercier" , , , Zhaoyang Huang , Subject: [PATCHv3] mm: remove '!root_reclaim' checking in should_abort_scan() Date: Wed, 18 Mar 2026 09:15:58 +0800 Message-ID: <20260318011558.1696310-1-zhaoyang.huang@unisoc.com> X-Mailer: git-send-email 2.25.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-ClientProxiedBy: SHCAS03.spreadtrum.com (10.0.1.207) To BJMBX01.spreadtrum.com (10.0.64.7) X-MAIL: SHSQR01.spreadtrum.com 62I1GBap066683 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unisoc.com; s=default; t=1773796574; bh=SUl7xz/kUSQqXnKKGh/x2QNXKHhN5Wx+n3klBSX56t8=; h=From:To:Subject:Date; b=F29JCSOQ+gNJuiNuwVPmL9qCZMSaaAM9fEJe3lrZ2VWJgqYQhM7lbGBhV23apVME5 sNkyNSnbI9dq/64iDqZZdabSBZXzjnRVE5BtKzEpqs7JUK56VMWejB/WJwPlaNQr2G v2KUVWKVraVnn/J8pxRINZRz/1DdQYpDu31MbAZTr6xqOheiFdmpoQYPq28uPnH8qO QlZuH5ASfGHjXDaNaSIaIOCeskPRqqEWZvpVzoPNAf+zHOppWmrK7naLcWw5XrTTan 40HYhBjBVQbVpr44coh4n4Vig+2sJ4U2QD/rfH6nhphuGOeLihq93aY9zYGJtdBbn4 Lx28XAs9g6cxg== Content-Type: text/plain; charset="utf-8" From: Zhaoyang Huang Android systems usually use memory.reclaim interface to implement user space memory management which expects that the requested reclaim target and actually reclaimed amount memory are not diverging by too much. With the current MGRLU implementation there is, however, no bail out when the reclaim target is reached and this could lead to an excessive reclaim that scales with the reclaim hierarchy size.For example, we can get a nr_reclaimed=3D394/nr_to_reclaim=3D32 proactive reclaim under a common 1-N cgroup hierarchy. This defect arised from the goal of keeping fairness among memcgs that is, for try_to_free_mem_cgroup_pages -> shrink_node_memcgs -> shrink_lruvec -> lru_gen_shrink_lruvec -> try_to_shrink_lruvec, the !root_reclaim(sc) check was there for reclaim fairness, which was necessary before commit 'b82b530740b9' ("mm: vmscan: restore incremental cgroup iteration") because the fairness depended on attempted proportional reclaim from every memcg under the target memcg. However after commit 'b82b530740b9' there is no longer a need to visit every memcg to ensure fairness. Let's have try_to_shrink_lruvec bail out when the nr_reclaimed achieved. Suggested-by: T.J.Mercier Reviewed-by: T.J.Mercier Signed-off-by: Zhaoyang Huang Acked-by: Qi Zheng Acked-by: Shakeel Butt --- Patchv2,v3: update commit message --- --- mm/vmscan.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 0fc9373e8251..10f1e7d716ca 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -4839,10 +4839,6 @@ static bool should_abort_scan(struct lruvec *lruvec,= struct scan_control *sc) int i; enum zone_watermarks mark; =20 - /* don't abort memcg reclaim to ensure fairness */ - if (!root_reclaim(sc)) - return false; - if (sc->nr_reclaimed >=3D max(sc->nr_to_reclaim, compact_gap(sc->order))) return true; =20 --=20 2.25.1