From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f49.google.com (mail-yx1-f49.google.com [74.125.224.49]) (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 ADF7E35C188 for ; Wed, 7 Jan 2026 17:46:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.49 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767808030; cv=none; b=nQApWnDMwQAckkfth+y5FWK05pdlb0DOjv8GGSxu/sVpKYiGDRRpmwTxf5bGD4vH67Z+5RJ6yzp16KV22ZSRzqeBGZRDpF6Cp49oYJ7LGE4ccalLTz5+jyyrsI/bzMbza3On/3WwuSN/1jXzAD2Mo+lgzHHKwEFYnXS1sGJ2sAg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1767808030; c=relaxed/simple; bh=4uobWbzZB+mUcXtfTSman5xXRsuTq3d9DwR/OI1lJho=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=R2zS5IFiqiVrAhXSrTd0/TqQlSzltBlKF3tLux+8OPfX9Js09ktwOY630yWbLm+36v/CXRTZYey3Mffolho6XajzdmJ/DhyZH3B8T/HiSYr3W2tpAolKmw0JwDNv/yt9g8vz0RfiHiYY000I8zKfbX9vg45n/HwoyXjD5o8Mq5U= 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=DoqlqY9M; arc=none smtp.client-ip=74.125.224.49 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="DoqlqY9M" Received: by mail-yx1-f49.google.com with SMTP id 956f58d0204a3-64472c71fc0so2414194d50.0 for ; Wed, 07 Jan 2026 09:46:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1767808015; x=1768412815; 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=Yq+hRv7j5U3La5Im0Ih8VHvIWX+RS+XOn+51KiKPnNc=; b=DoqlqY9MMzmxbRbTgsnsfjcmWQeHZq5daLhGXftNmyp2nN/I3p9051J72WwxkbNAXK 0rAzSrGcg1QWeJnEHKJCve2hvrXyYJEntFzqm3rs6O1xsFVzoT9FOZ11iWbD8KR2glzL dxDXkHo04I4mAAGhWE5rNoU99LDbcq+e19Z3n0BD6/1LCY7wRKGSphWJ57OT/KgLnqKo wOzmdizV5GCjsI+5ZclNuoVrLAIg1AooelQHaiPEe6orDjmrK9CWZ4BYVhWBdXKq+4Pl huBtTtaf8kECKMEWG5Lzp35JS51TiqfVRyMx4SRzjPv4UVGCYFaxGistHFfxE+Yk7IS6 G/hw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1767808015; x=1768412815; 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=Yq+hRv7j5U3La5Im0Ih8VHvIWX+RS+XOn+51KiKPnNc=; b=xU5SBxQYjHyvg0qWZJ6m1t4bfPr6j8GywgnWzj1NQAH87iq7JPCLQ3T1qjLX8LoCsC hiYT8U3u+WndydaqOsTzSWHTqpGHiHOMmY/vinZ6bWOZ/qQl8lHI7KyfsNyNZzXxCbC8 VaDsPPkMXXFZztiaIDBxNoYFmVEc9SRwM7aX+g9NhZR6Q3O1qTQinOO/iJZHFuJKmz/r 5C+GCdT+apTJfGSlDq86O2IgJDYtCXP2VVc0SOx/xopUsSSARiXjXKYV9iJFUjGoeoqZ hIJeLVbmTuxLnBNjEl0CwS6bSmQAgzXt1/vwb2BYGWagumEl6cNo0itkv5rYJqu4pzLa 8txA== X-Forwarded-Encrypted: i=1; AJvYcCXfGQ9PbjB2GeO3Gc5JdAUTO9LzfgFyzXC6qwV2l+UJNCpwxqtzPgr0hnVqOjnTV38SkxtFjsSMF6lQJ8w=@vger.kernel.org X-Gm-Message-State: AOJu0YyLmMLWQJY+53CK7HRlSuHcpRAhZU7o/cE8Lr175FrFk7MSQpsd mqb+H0SnxaLEEOM9pemh4JI5MMwUEpL8algUCXDz1+mlQzs2fCE3YuvY X-Gm-Gg: AY/fxX75ZZjNQ4CJLLoJFY8lZ77vuncGfo0jQgHZ3E+ViTTGzGo2fYJFBvFwwQ0PgMs hTQuEKcv5FVzCqkGmy80wpzpDtzT535qdmWQ3P9HqdNQVYFxJK2WF1MHLoS8GZP4t9uHWHotom2 UDRBZvinnH650uC1Jwx5t9JoL0943nNmV3aj/1D5XOUE8/wjYlRSBcV4LIrH/z/V4Ru7O+ohJ4o wbGZT2edEjddFKn5mNw6xgFooBzNsHpjLRtZrOqJfaq6niCobyywoKahB2kEh6d7M3soJvIkGyz Ki9Xg3Kw0aYUVCqL1gsf0lu21GMiUlVLemT6xbY1uMcqZ3cJuYoDqRR479liEjczUD9/A0K6YFV KFmAO8A/I//j3RwzgPQZ56PyyCyOgjZT82vKRepYmJEhf5tuUS77n3zEKvEacEl0z6WnJM6hJMC bC9lxTic2xvG4pnuD6LrFNRA== X-Google-Smtp-Source: AGHT+IFKZaI963qI2lfsjYtpouBpGoUt/GmE53ZOTA+tpen6+LZ/djh9xlNgv78cZInX83vFCG3OfQ== X-Received: by 2002:a05:690e:1248:b0:646:5127:9cde with SMTP id 956f58d0204a3-64716b392c0mr2943407d50.14.1767808014642; Wed, 07 Jan 2026 09:46:54 -0800 (PST) Received: from localhost ([2a03:2880:25ff:5e::]) by smtp.gmail.com with ESMTPSA id 956f58d0204a3-6470d7f7c04sm2317224d50.2.2026.01.07.09.46.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 07 Jan 2026 09:46:54 -0800 (PST) From: Joshua Hahn To: Bing Jiao Cc: linux-mm@kvack.org, Andrew Morton , Johannes Weiner , David Hildenbrand , Michal Hocko , Qi Zheng , Shakeel Butt , Lorenzo Stoakes , Axel Rasmussen , Yuanchu Xie , Wei Xu , linux-kernel@vger.kernel.org Subject: Re: [PATCH v1 0/2] mm/vmscan: optimize preferred target demotion node selection Date: Wed, 7 Jan 2026 09:46:52 -0800 Message-ID: <20260107174652.3973445-1-joshua.hahnjy@gmail.com> X-Mailer: git-send-email 2.47.3 In-Reply-To: <20260107072814.2324646-1-bingjiao@google.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, 7 Jan 2026 07:28:12 +0000 Bing Jiao wrote: Hello Bing, thank you for your patch! I have a few questions about the motivation about this patch. > In tiered memory systems, the demotion aims to move cold folios to the > far-tier nodes. To maintain system performance, the demotion target > should ideally be the node with the shortest NUMA distance from the > source node. > > However, the current implementation has two suboptimal behaviors: > > 1. Unbalanced Fallback: When the primary preferred demotion node is full, > the allocator falls back to other nodes in a way that often skews > toward zones that closer to the primary preferred node rather than > distributing the load evenly across fallback nodes. I definitely think this is a problem that can exist for some workloads / machines, and I agree that there should be some mechanism to manage this in the demotion code as well. In the context of tiered memory, it might be the case that some far-nodes have more restrited memory bandwidth, so better distribution of memory across those nodes definitely sounds like something that should at least be considered (even if it might not be the sole factor). With that said, I think adding some numbers here to motivate this change could definitely make the argument more convincing. In particular, I don't think I am fully convinced that doing a full random selection from the demotion targets makes the most sense. Maybe there are a few more things to consider, like the node's capacity, how full it is, bandwidth, etc. For instance, weighted interleave auto-tuning makes a weighted selection based on each node's bandwidth. At least right now, it seems like we're consistent with how the demotion node gets selected when the preferred node is full. Do your changes lead to a "better" distribution of memory? And does this distribution lead to increased performance? I think some numbers here could help my understanding and convince others as well : -) > 2. Suboptimal Target Selection: demote_folio_list() randomly select > a preferred node from the allowed mask, potentially selecting > a very distant node. Following up, I think it could be helpful to have a unified story about how demotion nodes should be selected. In particular, I'm not entirely confident if it makes sense to have a "try on the preferred demotion target, and then select randomly among all other nodes" story, since these have conflicting stories of "prefer close nodes" vs "distribute demotions". To put it explicitly, what makes the first demotion target special? Should we just select randomly for *all* demotion targets, not just if the preferred node is full? Sorry if it seems like I am asking too many questions, I just wanted to get a better understanding of the motivation behind the patch. Thank you, and I hope you have a great day! Joshua