From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-171.mta0.migadu.com (out-171.mta0.migadu.com [91.218.175.171]) (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 AFEBD27CCF0 for ; Fri, 24 Jul 2026 03:47:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.171 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784864848; cv=none; b=s68P01A2K9IPVfje9sMHD2YyY7QhIS2hHR82KmHkxM24fwuE09dzQBJI8B50ALDiuuLPd7oks+nNF6Cln/gaDsXi9iBISQ0XfR7OYN1Y3aF8qN8cOu9H+u/twM2aRaNWvFMhSKM0lVqRD1c/LHSBNJ8GF8F7XJjHcwvHdHf/wFs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784864848; c=relaxed/simple; bh=x/AqtmYoB6z3hdQYa8GoFEgngecsdAmlAjAODp3JctE=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=WQk2MY5lV+Gx5VkY+FsEsgx8XhseUpsmZ3Eq61ttZ/FkPD+mvbiZOrTcZ37RNZaFXUh78v7PjuDK9cfikW2tP3vzi5fejMyUORG5GkxMp/GLteSYixD4iv/PFXC8qEnKdSs3QK8k1+ja0WM/YWKWuMrc/7Ef4pg1G0sI6Zm6G1M= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=UsWH2ZJp; arc=none smtp.client-ip=91.218.175.171 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="UsWH2ZJp" Message-ID: <02c1c551-0a0a-4cc2-96c3-5ec0d9f71086@linux.dev> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1784864843; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=OnO8IVbS/xiFlAYBjblWiXkuYuos7gLxr/7vW4NvRfU=; b=UsWH2ZJplnwBFimh4I2eVGiyoLQlRQ/XzolSlIZ87NzTJ8R/t77YBmFitCXzb+KsebRRZP UWCUSN5vbPS5AQhAmw9SLkjYSWpF9C3SkNjMzRKvi/D1M0dpAwBeucz5v/od/IUZPJniza Xx0s9z6pyoR9eaYxg0NlDdRQxvZqUdI= Date: Fri, 24 Jul 2026 11:47:15 +0800 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Subject: Re: [PATCH] mm/mglru: fix memcg protection for global proactive reclaim To: Andrew Morton Cc: Johannes Weiner , David Hildenbrand , Michal Hocko , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , Kairui Song , Barry Song , Axel Rasmussen , Yuanchu Xie , Wei Xu , Yu Zhao , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Ridong Chen References: <20260723130559.2343690-1-ridong.chen@linux.dev> <20260723165804.f4899595c0523bb16af292fd@linux-foundation.org> X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Ridong Chen In-Reply-To: <20260723165804.f4899595c0523bb16af292fd@linux-foundation.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Migadu-Flow: FLOW_OUT On 7/24/2026 7:58 AM, Andrew Morton wrote: > On Thu, 23 Jul 2026 21:05:59 +0800 Ridong wrote: > >> memory.min/low is silently bypassed for MGLRU during global proactive >> reclaim (writing to the root memory.reclaim). It can be reproduced as >> follows: >> >> ... >> >> Factor the tree traversal out into update_memcg_protection() and call >> it from lru_gen_shrink_node() for the non-kswapd path, so the protection >> is computed before shrinking. kswapd keeps computing it in >> lru_gen_age_node(), which also needs it for the min_ttl OOM check. >> >> Fixes: e4dde56cd208 ("mm: multi-gen LRU: per-node lru_gen_folio lists") > > Do we want cc:stable on this fix? > > Sashiko said a couple of things - the memcg ref leak looks real: > https://sashiko.dev/#/patchset/20260723130559.2343690-1-ridong.chen@linux.dev > Sashiko said: When breaking out of the loop early here, do we need to call mem_cgroup_iter_break(NULL, memcg) to release the reference? Since mem_cgroup_iter() holds a reference to the active cgroup css, exiting without dropping it could cause memory cgroups to leak and accumulate over time, eventually leading to kernel memory exhaustion. [ ... ] This is a bug introduced by this patch, and we will fix it. Regarding the performance regression: Placing update_memcg_protection() inside the lru_gen_shrink_node() non-kswapd path forces every direct reclaimer into an unbounded full cgroup tree walk. Will this cause severe performance regressions during global memory pressure? All allocating tasks entering global direct reclaim would concurrently traverse the entire memcg tree. This could lead to massive css->refcnt cacheline bouncing and system latency spikes, scaling negatively with the number of memory cgroups. Could this full tree walk be optimized or deferred so direct reclaimers avoid iterating every single cgroup? Since MGLRU global reclaim does not iterate over memcgs in the same way traditional LRU does (which traverses the hierarchy from top to bottom), it appears we are currently required to walk the full tree, similar to what kswapd reclaim does. Does anyone have a better approach in mind? -- Best regards Ridong