From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=209.127.231.115 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792662260; b=Mzy07Y9pYi5OWwm3Z8Rjt0t9zP5dcMj/Cmfle6FP8V4YivgRL313WbnjK5GfpxT9UbSv xirCnAsd/8d4H2rE/alnXuF+vzVwUIaheiZOGeecNAuMfZ1hWssIWAw/Z+dTyvWfFdoMK HaEpeo1XK4YiuX0Pci22SsF7ghoiDlwICFa6y8UoHuH1R42MRx5XKXv5JJfP+SuVmabad +6+P9M9uqISiiMkCLfmDz0l2FKYLL3rYT3F7N0X22b7ZHx1vwwTDgCxpVjRegaGa8GPRM nMXh9PNwNCRo6IH6CAdqOxH47IY2c4XWaGt9+PrLkCl4qhw9pcHDAbhfMSNEUP1jFZg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792662260; h=DMARC-Filter:DKIM-Signature:Message-Id:Cc:From:X-Original-From: X-Lms-Return-Path:To:Mime-Version:Content-Type:User-Agent: Content-Transfer-Encoding:References:Subject:In-Reply-To:Date; bh=OUGHKG75J/Ha1UT9SfogPm3T2YK7q5WmnJNj8nl5ncM=; b=3PXndRWbmBp/+duHCrJqXupb7ZhcK+0SFaGpSHbrpFhvzo4DoNiLCknK6X9XMfvj63oZ 4GBG9wCSFNWpQslALO80bAd2RUUosabOyexkcWsBzbVFsUPofa40PhkQVyfYUnLhVvcHx LFCPi5tzuziGto2liQyOBC9devrXi8nk+2Rayqb1D8vqHcZfq9mkjtdjrg/fTiMu6XITI zjoJpCGjOItGf6STfy+P+2ALZlftrv5MrpY3y6qLGu4aDuRpyys4JekVbLOEWJKYX8Uj7 4HWzwZEc1r53bo3PNqNTTlv0A3o4T2H7ytlTVAGnlSvdhRpAols9tHK/cQHS3RO0BLg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=bytedance.com; spf=pass smtp.mailfrom=bytedance.com; dkim=pass header.d=bytedance.com header.i=@bytedance.com header.a=rsa-sha256 header.s=2212171451 header.b=QgXszFg8; arc=none smtp.remote-ip=209.127.231.115 Received: from va-2-115.ptr.blmpb.com (va-2-115.ptr.blmpb.com [209.127.231.115]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 853C5606A321 for ; Thu, 22 Oct 2026 09:44:19 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 853C5606A321 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=bytedance.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=bytedance.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key, unprotected) header.d=bytedance.com header.i=@bytedance.com header.a=rsa-sha256 header.s=2212171451 header.b=QgXszFg8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; s=2212171451; d=bytedance.com; t=1792662252; h=from:subject: mime-version:from:date:message-id:subject:to:cc:reply-to:content-type: mime-version:in-reply-to:message-id; bh=OUGHKG75J/Ha1UT9SfogPm3T2YK7q5WmnJNj8nl5ncM=; b=QgXszFg8BQyFzMHr+mS9D6ndBB9hF1GzlRV9C+V1WtRI0Da2uvUB2pOW7NBZM91KwRp8ge ECBtD77JopJSEPqWADA2RGCbdf7HlvhOPgm5jeY0WEM0y2v4dR6+vFliA+LfOGIzagobu0 ZXhAArMow6hYHmdIIsTdsSMcBSXl6TQNvhAJ4GADIBJmpXqZtc2LqaHnDuLrIxhZfzj0hc rnV2MJmkp9PmZx5bceIzAUPApsI/MhQ+YmpZcp5zCIHi5wY/EcEzbAbpdAdtmYbiR/D8Q4 ozameHasAU8fGA7RTuzeaxBP4GVu2EYi9bL4yR0O8WyC/EPfdjdbMh0cRkGcVQ== Message-Id: <9b715272-3ed9-42da-a6ae-467e8ae00c0b@bytedance.com> Cc: , , , , , , , , , , , , , , , From: "Li Zhe" X-Original-From: Li Zhe X-Lms-Return-Path: To: "Gregory Price (Meta)" X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 User-Agent: Mozilla Thunderbird Content-Transfer-Encoding: 7bit References: <20261019141401.11927-1-lizhe.67@bytedance.com> <30457046-a662-4ff7-a6a8-100398d7a806@bytedance.com> <179264138036.2549665.17429111144570830454.b4-reply@b4> Subject: Re: [RFC 0/2] mm: add source selectors to memory.reclaim In-Reply-To: <179264138036.2549665.17429111144570830454.b4-reply@b4> Date: Thu, 22 Oct 2026 17:43:49 +0800 On 10/22/26 11:56 AM, Gregory Price (Meta) wrote: > On 2026-10-20 21:01 +0800, Li Zhe wrote: >> On 10/20/26 12:10 AM, Gregory Price wrote: >> >> I agree that the kernel reclaim and demotion behavior still has room for >> improvement, and the watermark changes and the bottom-up proactive/async >> reclaim idea you mentioned may be useful to explore for some tiering >> scenarios. But I think there is also an unavoidable userspace policy >> component here. The kernel can improve whole-cgroup reclaim, but it >> cannot know every controller's placement goal. >> >> For example, one controller may want to keep a specific per-tier >> resident ratio for a cgroup. Another use case, as Joshua pointed out in >> another reply, is reclaiming from a lower tier first so that later >> top-tier reclaim has room for demotion. A single default memory.reclaim >> algorithm cannot express these per-cgroup policy choices. >> > The latter of these should probably be some level of the system default, > that's why I brought it up as well. (proactive reclaim should prefer to > make progress from the coldest tier first, then work its way up). > > I'm not convinced a reclaim interface is the right way to affect a > per-tier resident ratio policy. That feels like a hack to get around > solving the harder problem of something like tiered memcg counters > (which would otherwise drive reclaim to work exactly the way you > describe for resident ratios). Thanks for the detailed comments. I agree that improving the default proactive/async reclaim behavior can be useful, and I also agree that tiered memcg counters/limits would be useful. I do not see source=nodes as a replacement for those directions. They solve different parts of the problem: tiered counters/limits provide accounting and policy targets, while source=nodes is only an actuator for proactive reclaim. So I think these directions are compatible. A better default reclaim policy or tiered memcg limits can improve kernel-driven behavior, while source=nodes gives userspace an explicit way to apply reclaim pressure to a selected resident source. > >> I am not sure whether changing the default whole-cgroup reclaim behavior >> in this direction could affect existing userspace dependencies. In the >> old nodes= discussion, Mina mentioned that Meta's reclaim stack relied on >> memory.reclaim triggering demotion [1]. >> > Yes and on its surface this is something I could see Meta using, however > I question whether we're simply trying to find a convenient way around > fixing reclaim to do the right thing (not invert the LRU, apply per-tier > memcg limits, etc). That is fair, and I do not intend this to avoid improving reclaim or adding better tier-aware memcg accounting. A better memory.reclaim algorithm would also make source=nodes more useful, because source=nodes still uses the existing reclaim path after selecting the resident source. The goal here is narrower: expose a source-scoped proactive reclaim actuator while keeping the kernel's reclaim policy in control. The old nodes= discussion had ABI problems, but it also showed that a nodemask-like source selector is a useful primitive for finer-grained proactive reclaim control [1]. > >> I also do not intend source= to lock in current reclaim implementation >> details. It should stay consistent with the current design: source= only >> selects the resident source to which reclaim pressure is applied, while >> the kernel remains free to change the reclaim policy. >> > Well, sort of, you get exposed to the implementation details by having > to negotiate what is considered progress under different scenarios. > > Lets take one example - what should happen when: > - 2 node system, node0=DRAM, node1=CXL > - zswap is configured > - echo 1G source=nodelist:1 > memory.reclaim > - node 1 is pressured, zsmalloc falls back to node0 to allocate > > Should that be considered progress? We reclaimed from node1, but > increased pressure on node0 - which might have kicked kswapd or memcg > accounting to demote memory from node0 to node1. > > Should zswap also take that nodelist as a constraint? This is a good example of why source=nodes should not be described as a one-shot net footprint guarantee. Assuming source=nodes:1, the request applies reclaim pressure to memcg memory resident on node1. That may free some space on node1 in the short term, which can provide room for a later node0-to-node1 demotion step. If zswap allocation, kswapd, or memcg reclaim later moves pressure back across tiers and node1 usage rises again, that is part of the dynamic reclaim/tiering behavior. So userspace cannot rely on one write to memory.reclaim to produce a final per-node distribution. The intended usage is a feedback loop: the controller observes the memcg's resident distribution, chooses the source nodes it wants to relieve, applies source-scoped reclaim pressure, observes the new distribution, and iterates. I do not think this patch should make source=nodes constrain zswap pool allocations. That would be a different and much stronger semantic. The current intent is only to constrain the resident source from which memcg reclaim applies pressure, while completion accounting remains the existing memory.reclaim accounting. > > At the very least i think you need to add details in your cover that > demonstrates the process of doing something like per-node resident > ratios, and show that it works as you intend. Agreed. I will update the cover letter to make this model clearer. I will also make clear that source=nodes is not a final net per-node footprint guarantee and does not change memory.reclaim completion accounting. [1] https://lkml.org/lkml/2022/12/14/194 Thanks, Zhe