From nobody Mon Apr 6 23:27:55 2026 Received: from SHSQR01.spreadtrum.com (mx1.unisoc.com [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 1A1443BFE23 for ; Tue, 17 Mar 2026 12:33:29 +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=1773750813; cv=none; b=fa4Gdhjfd0fxCMtC1Hc0omyFHXoOimSJHwkpuI52LeFii8QjTPiD76rx1cg9GuSEHjbZwfczef+mpwi0knJRMN6nJen6bCgtPgu+tpkTa+otQjT7rrrmkHJfqSqaFKGwOjBwJsqL2wLUUmsKpgAVP7mscpZ47OfxiSl2hvGc4QQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773750813; c=relaxed/simple; bh=XeylR/SGmluQoAWVlD7yCUFqeWtCmxBe/yIq0ZbXmVs=; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; b=X7KQfDdReS1lFi99LhfexjOFlyU+V1XpKe1dAHrHXZfXc7AYWtWDH4jlzjeDG1bL3MWp3OJvro8fouPtkys3hUPiiv2TvkKyt0/PDygdvsYzD9DqDcGCdpa7yeRt6JFHP7EWRL1K0V8jVRO2DOBc3TJjeOCgVBEMVnMWBb/6zdw= 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=yVjpuC/w; 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="yVjpuC/w" Received: from dlp.unisoc.com ([10.29.3.86]) by SHSQR01.spreadtrum.com with ESMTP id 62HCV3Lq000571; Tue, 17 Mar 2026 20:31:03 +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 4fZrqz1bW0z2PRM8y; Tue, 17 Mar 2026 20:29:35 +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; Tue, 17 Mar 2026 20:31:01 +0800 From: "zhaoyang.huang" To: Andrew Morton , Michal Hocko , "T . J . Mercier" , , , Zhaoyang Huang , Subject: [PATCHv2] mm: remove '!root_reclaim' checking in should_abort_scan() Date: Tue, 17 Mar 2026 20:30:37 +0800 Message-ID: <20260317123037.1651424-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: SHCAS01.spreadtrum.com (10.0.1.201) To BJMBX01.spreadtrum.com (10.0.64.7) X-MAIL: SHSQR01.spreadtrum.com 62HCV3Lq000571 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unisoc.com; s=default; t=1773750668; bh=OvF++IGjKAaqWGUfX+qLkBmP1nNWElSB0WIRzdy2sJE=; h=From:To:Subject:Date; b=yVjpuC/wMiYEu8zirgdNZGtTop91/IonX+5fs6I4odHpG4pBrcctokj/fX9uh6fqT KlXk3HO4TZeasGpALvwB1pYtewUnCYRN/kccyylHF8OIBuSyL9ckOMp6q+c7mcV3Bn NVoToBaVkBWFtYvVUo8y1pmWaaqJUqfTJBPnyljA5hwKDyswNC4ZBiy7PyamoIX9MC iZou+7q4ca72qWk/uVutruyXUN3c0rvCv99BGcUrkeV8fA92ZAmvz16UweXMPkX+KS J009s08AODg98gZ3gLeT+dQ8L6jMZrMQQAOos93hSW3c6aobtvsE16WFgCeRd/+CwR MENUk4FqY+yfg== Content-Type: text/plain; charset="utf-8" From: Zhaoyang Huang Nowadays, ANDROID system replaces madivse with memory.reclaim to implement user space memory management which desires to reclaim a certain amount of memcg's memory. However, oversized reclaiming and high latency are observed [1] as there is no limitation over nr_reclaimed inside try_to_shrink_lruvec when MGLRU enabled. Besides, this could also affect all none root_reclaim such as reclaim_high etc. 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, horray. The problem is for large lruvecs, the lack of a check against sc->nr_to_reclaim inside try_to_shrink_lruvec (caused by the continued presence of the !root_reclaim(sc) check) can cause overreclaim. The non-MGLRU implementation in shrink_lruvec already checks nr_reclaimed against nr_to_reclaim. [1] test log which shows a nr_to_reclaim=3D32 pages proactive reclaim ended with nr_reclaimed=3D394. [ 485.100981] memcg iter ffffff8086535a00 nr_to_reclaim 32 nr_reclaimed 0 [ 485.106927] memcg iter ffffff8086535a00 nr_to_reclaim 32 nr_reclaimed 127 [ 485.109652] memcg iter ffffff80744e1400 nr_to_reclaim 32 nr_reclaimed 127 [ 485.112255] memcg iter ffffff80744e4600 nr_to_reclaim 32 nr_reclaimed 127 [ 485.115766] memcg iter ffffff8150306e00 nr_to_reclaim 32 nr_reclaimed 191 [ 485.125635] memcg iter ffffff8157608a00 nr_to_reclaim 32 nr_reclaimed 191 [ 485.131366] memcg iter ffffff8157754600 nr_to_reclaim 32 nr_reclaimed 216 [ 485.136688] memcg iter ffffff8157752800 nr_to_reclaim 32 nr_reclaimed 216 [ 485.140495] memcg iter ffffff8157755000 nr_to_reclaim 32 nr_reclaimed 216 [ 485.147322] memcg iter ffffff8159461400 nr_to_reclaim 32 nr_reclaimed 216 [ 485.150605] memcg iter ffffff8159466400 nr_to_reclaim 32 nr_reclaimed 216 [ 485.158260] memcg iter ffffff8159460a00 nr_to_reclaim 32 nr_reclaimed 216 [ 485.160819] memcg iter ffffff8159460000 nr_to_reclaim 32 nr_reclaimed 216 [ 485.163200] memcg iter ffffff8159463c00 nr_to_reclaim 32 nr_reclaimed 216 [ 485.171778] memcg iter ffffff808912ee00 nr_to_reclaim 32 nr_reclaimed 216 [ 485.174156] memcg iter ffffff808912a800 nr_to_reclaim 32 nr_reclaimed 216 [ 485.179110] memcg iter ffffff814bd3a800 nr_to_reclaim 32 nr_reclaimed 216 [ 485.181537] memcg iter ffffff814bd39e00 nr_to_reclaim 32 nr_reclaimed 216 [ 485.184877] memcg iter ffffff814bd3da00 nr_to_reclaim 32 nr_reclaimed 219 [ 485.187245] memcg iter ffffff814bd38a00 nr_to_reclaim 32 nr_reclaimed 219 [ 485.189654] memcg iter ffffff814bd38000 nr_to_reclaim 32 nr_reclaimed 219 [ 485.192029] memcg iter ffffff814bd3bc00 nr_to_reclaim 32 nr_reclaimed 219 [ 485.194509] memcg iter ffffff814bd39400 nr_to_reclaim 32 nr_reclaimed 283 [ 485.197107] memcg iter ffffff814bd3c600 nr_to_reclaim 32 nr_reclaimed 330 [ 485.201361] memcg iter ffffff814bd3ee00 nr_to_reclaim 32 nr_reclaimed 394 Suggested-by: T.J.Mercier Reviewed-by: T.J.Mercier Reviewed-by: Michal Hocko Signed-off-by: Zhaoyang Huang --- Patchv2: 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