From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794590858; b=nEVBoWqbARn08/ndbU2z1N3pcsKDEjyjHTmFkMsp5INiSB23WYmtwEV5Tw2+6m9AworO bwowxFiui+MuRVDtHr0dhyo8EzfNhI6XM2C8fv5nuROPyVtdQKo+EaeWn9LDXY5EKbLcB spc1tVmUF8eBJfEc5Ieck81qX7ZUsxz/ICBf5fqmxKoBvIwIOQEra3OGpQ1ET2bwOzKl0 AzYgOm5HSHkUcK8oIz07WBqPK8zEN8j6awqY9Zu/jdESC49SUSuPN5t3DIMdyVu1wDNIA g5vJO6S2KdjbeIZ157eVNS+TqWNLfhtLAfaFn8b97xiMtoT1Fjn3mTzcC16KlZVQXJA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794590858; h=Received:DKIM-Signature:From:To:Cc:Subject:Date:Message-ID:X-Mailer: In-Reply-To:References:User-Agent:X-stable:X-Patchwork-Hint: MIME-Version:Content-Transfer-Encoding; bh=4mBGYEwdBXbqyW5t4wu7yP6SRj4eS2UliaMosh15koM=; b=2Ll6/Tyj+WxNtObRewHP8NbB0KCTVw8IPmU15MvU+sLyDlm1krAMpNdaJB9imB1rWwFN 1T1fKMsBKCxm7rPYm8nTllUT2WM8vI17vOT/geC4zm1nvW/BdDPErxjMi2UxZ5eIRzuZM Q3vdnNSfcdaoD5UA9554FF/58ac9aG1/A3Y7oqaBcxzpGBZC1+yuZanxm6/bl+NdjgB7H xDJv5NhAkYuuAOcmWuF8qlPR+d5vWfTm48K3PWzZi2NZGuBDPcigpLjdaQIIGEc0Xk+bk vV7oLa/Z2Kxet5hXX8qaVLtGk0ZBS7oJ/+SbiSBS0EHQmH03vxLmc/ySy7CZ/h1RULg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=jfDaPTCB; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 20E89606A8BE; Fri, 13 Nov 2026 17:27:38 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linuxfoundation.org header.i=@linuxfoundation.org header.a=rsa-sha256 header.s=korg header.b=jfDaPTCB Received: by smtp.kernel.org (Postfix) with ESMTPSA id A84EF1F000C4; Fri, 13 Nov 2026 17:27:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linuxfoundation.org; s=korg; t=1794590858; bh=4mBGYEwdBXbqyW5t4wu7yP6SRj4eS2UliaMosh15koM=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=jfDaPTCBfakioCprKRNgqGKi/crkkdrOc+XSrtjwoAXrr8il538EEYZeeUXpDVo1D dGDU2ExkWI0GlYc/H2TOwCYnfzI3DmAUDZmfUH2fnQyVB62QxPZUkp/HkjCEiYl00H aFjxzF7km59fM0ERBdkdvbbB/hpr4+1uKlllmnAM= From: Greg Kroah-Hartman To: stable@vger.kernel.org Cc: Greg Kroah-Hartman , patches@lists.linux.dev, Zhaoyang Huang , "T.J.Mercier" , Shakeel Butt , Qi Zheng , Barry Song , Kairui Song , Johannes Weiner , Michal Hocko , Rik van Riel , Roman Gushchin , Yu Zhao , Axel Rasmussen , Yuanchu Xie , Wei Xu , Andrew Morton , Sasha Levin Subject: [PATCH 6.12 016/670] mm: remove !root_reclaim checking in should_abort_scan() Date: Fri, 13 Nov 2026 10:43:00 -0500 Message-ID: <20261113153811.735104662@linuxfoundation.org> X-Mailer: git-send-email 2.56.0 In-Reply-To: <20261113153811.177190860@linuxfoundation.org> References: <20261113153811.177190860@linuxfoundation.org> User-Agent: quilt/0.69 X-stable: review X-Patchwork-Hint: ignore X-Mailing-List: stable@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 6.12-stable review patch. If anyone has any objections, please let me know. ------------------ From: Zhaoyang Huang [ Upstream commit 19999e479c2a38672789e66b4830f43c645ca1f2 ] 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=394/nr_to_reclaim=32 proactive reclaim under a common 1-N cgroup hierarchy. This defect arose 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. Link: https://lore.kernel.org/20260318011558.1696310-1-zhaoyang.huang@unisoc.com Link: https://lore.kernel.org/20260212032111.408865-1-zhaoyang.huang@unisoc.com Signed-off-by: Zhaoyang Huang Suggested-by: T.J.Mercier Reviewed-by: T.J. Mercier Acked-by: Shakeel Butt Acked-by: Qi Zheng Reviewed-by: Barry Song Reviewed-by: Kairui Song Cc: Johannes Weiner Cc: Michal Hocko Cc: Rik van Riel Cc: Roman Gushchin Cc: Yu Zhao Cc: Axel Rasmussen Cc: Yuanchu Xie Cc: Wei Xu Signed-off-by: Andrew Morton Signed-off-by: T.J. Mercier Signed-off-by: Sasha Levin --- mm/vmscan.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index 512a31d7ae9e6..de7a50570db36 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -4752,10 +4752,6 @@ static bool should_abort_scan(struct lruvec *lruvec, struct scan_control *sc) int i; enum zone_watermarks mark; - /* don't abort memcg reclaim to ensure fairness */ - if (!root_reclaim(sc)) - return false; - if (sc->nr_reclaimed >= max(sc->nr_to_reclaim, compact_gap(sc->order))) return true; -- 2.53.0