From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f172.google.com (mail-yw1-f172.google.com [209.85.128.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id A1EDD47DFAE for ; Wed, 21 Jan 2026 15:54:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769010857; cv=none; b=rxenIMB7MRM+t0HciL77YDGS1o+3IPCnKa3CNaPBKFK2P1shoplaDerNy4dbEthQ/oz0N51oG+B1hjQnNxLLiNKjVIOUWz8lmWNjPPs4rv7COz2/fPLh/GM8prLUn3jLv/2jb+Q8X2tEZzNcqxwJ3eivJD/Bm13LVaSgRMSfGpQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769010857; c=relaxed/simple; bh=sLg6bD4UIiHZfGazqW2Zz6MyldCNKmkYT8727e+BT2E=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=mb1LgQOo6Q11rySzTRATejbkMqF0TSe1Z1UrY4R1iQUeZCcG/QtYUSjmwAq/ySG64xAcOHBZzmUz+1iXsWMqKjHTi6kP75tXVix5EGkPFcvFk9Z2IGd1pHANudjh15y+pfKZw4kFgQUZfoNtaxH+ud6LcVbUywdJmY9K4v8rpd0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=JAkokkjW; arc=none smtp.client-ip=209.85.128.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="JAkokkjW" Received: by mail-yw1-f172.google.com with SMTP id 00721157ae682-78fc4425b6bso63667557b3.1 for ; Wed, 21 Jan 2026 07:54:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769010852; x=1769615652; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=N+b9RHMyh8YpEgryFPlqueFgoSWtvVkjnMCqvxBGKig=; b=JAkokkjWFBcSu0UULXjQaIRLdfi3GtV/Owlu6qjVjvoKXPJhLzLd9DZpYzQCzKQzRs zHGp1vu6N24z9rV+cWyZhplTJJUQb9gqyz121rTbvMdO82AH8wj2OMvaEC8x4jkzdWbv eo2XT0eamRdG+xKAEqSR2PT4BVtX335Zv+0LeO6p3mwqK4vDiMUgEmtUBT9U8wlEZ18Q 5yTpcs3Wmk9jAeVOmd2ayDfK9V9+M6rBPynHsfdW6mgE+rpxTVppwxsZWKMSG451++M3 Z8DFbNr49MBJKvQKgDD6wV6NDdXwCsIAudUb3g0vNr36T7DQgcpZofXumj10onfYdEWL KPjw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769010852; x=1769615652; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=N+b9RHMyh8YpEgryFPlqueFgoSWtvVkjnMCqvxBGKig=; b=KKUTuYe3Dug29zDYtWzZca3QE2/C8omjMJhmu7khGLHz3zPKmhwk3icc087Pw92FGB 2YChfI8I48Sjqc0fIVzO4luthVXgkaI6HLLy5ahSwq1JEvvHen+l8wxNVnnrNzHIEGGh XlUssTk/k7RgHIDueQd+6w1PnWQmsxmRKljjjPdZAtw5b3a+L7SxoQ3GgxGIoQx3TcR8 Uw2/3dxV+KgpFKOZyK8jUtgndAPYNSm7Gu0IIOxf2KuSVOjwqHPqsj2ySqRfd6mHgotp l0pOxJRqT17jOCdq0IUB7tcQ1X9f1RC66OkfBiq3b/MwFcuXtKTf0/gEotGRpojDHiNF JWMA== X-Forwarded-Encrypted: i=1; AJvYcCU+Bnx3T7lNhXgvEVLClFZ3MSYUoUyV0IW+2pMuN47kIxlufQHIZGWKbCxY3JUb24AUcf15QvV5DuZHVgo=@vger.kernel.org X-Gm-Message-State: AOJu0YyN5Z9EsfUfqHCk52ZGwEH3VCmjb863g4pgAHPa3zIhF46OYyA9 aF28ZV1vGdkLVVrLoanqcg515YubA+NoEl0jcrAiZUkBEUF69uYCEOKT X-Gm-Gg: AZuq6aLbfL+knlerp6dp6+LjvIJ+VymWBNiNM0hgVWiEGS6QYx9HJs6VGDd9Qwvs8E0 0iLsH17hjDR92FR2v5TwM2NstWj0Mdqa4BcUiTmrN8sLrtS9lfAYn3rjKjRpSn1thb9Ydncs+OG sIBYmsZQbvRRgGBPPvB1Rvo005mhvjD12g3RuGwD4/ByJ8Yfstp9BM/jtCfPmikDuHKnivWpbab b2idKhyyAChKyszbCvP69gxWi3dDTs3fuz6ZkEp9FfM6aVMzC1YR8KmDf1zPVbq7qLIVitAv90y E6yWUwDV+GkMA/xf5OX2ONu3VpsSRj+2QDlBSYefWkT4qcNgr0W50wmsnjjaE2DL16tkeVAWoG6 PIw1subiivx2MLZyKPEM1ONRSSCshPeU6D9P2uD7MP5JpOqmOO9hLr1/ObT4nCfVq9am6896GkL TswC0S/LLr X-Received: by 2002:a05:690c:c4e8:b0:78c:28b7:88e4 with SMTP id 00721157ae682-7940a4b09c7mr44532467b3.69.1769010852361; Wed, 21 Jan 2026 07:54:12 -0800 (PST) Received: from localhost ([2a03:2880:25ff:c::]) by smtp.gmail.com with ESMTPSA id 00721157ae682-793c689ccf8sm66033577b3.49.2026.01.21.07.54.11 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 21 Jan 2026 07:54:11 -0800 (PST) From: Joshua Hahn To: "zhaoyang.huang" Cc: Andrew Morton , Michal Hocko , Johannes Weiner , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Zhaoyang Huang , steve.kang@unisoc.com Subject: Re: [PATCH] mm: bail out when meet the goal of proactive memcg reclaim Date: Wed, 21 Jan 2026 10:54:10 -0500 Message-ID: <20260121155410.459018-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260121090620.559242-1-zhaoyang.huang@unisoc.com> References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Wed, 21 Jan 2026 17:06:20 +0800 "zhaoyang.huang" wrote: > From: Zhaoyang Huang Hi Zhaoyang, I hope that you are doing well! > The proactive memcg reclaim defines the specific target mem cgroup > as well as a certain number of memories, which is different to > the kswapd and direct reclaim that need to keep the fairness among > cgroups. This commit would like to introduce a criteria to have > proactive reclaim bail out when target mem cgroup could meet the goal > via its own lruvec, which means the reclaim would also go through the > whole tree if the iter start on the desendants. I think the motivation makes sense. If a user-initiated reclaim has already reclaimed the amount of memory that was requested, there's probably no need to continue traversing the tree and reclaiming more, and we can do an early exit. We also don't need to worry about fairness among the target memcg's descendants, because if the user cared about that then they would have specified one of the descendants as the target_memccg. But I would also like to go back to what Michal also pointed out in his reply -- why include target_memcg == memcg? Wouldn't we want this early bail out to happen down the memcg hierarchy as well? And most importantly, have you seen any issues in real-life as a result of this? Is writing to memory.reclaim too slow? Please let me know what you think. I hope you have a great day! Joshua > Signed-off-by: Zhaoyang Huang > --- > mm/vmscan.c | 11 +++++++++-- > 1 file changed, 9 insertions(+), 2 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index 670fe9fae5ba..5dcca4559b18 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -6028,8 +6028,15 @@ static void shrink_node_memcgs(pg_data_t *pgdat, struct scan_control *sc) > sc->nr_scanned - scanned, > sc->nr_reclaimed - reclaimed); > > - /* If partial walks are allowed, bail once goal is reached */ > - if (partial && sc->nr_reclaimed >= sc->nr_to_reclaim) { > + /* If partial walks are allowed, or proactive reclaim where > + * the target memcg is clearly defined that could let us ignore > + * the fairness thing, bail once goal is reached. > + * note: for proactive reclaim, the criteria make sense only > + * when target_memcg has both of descendant groups and folios > + * charged. Other wise, walk the whole tree under target_memcg. > + */ > + if ((partial || (sc->proactive && target_memcg == memcg)) && > + sc->nr_reclaimed >= sc->nr_to_reclaim) { > mem_cgroup_iter_break(target_memcg, memcg); > break; > } > -- > 2.25.1