From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) (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 202CF3DB30F for ; Tue, 14 Jul 2026 06:29:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784010577; cv=none; b=nU0hVRqDwQAUwEUKZz0poD09PMtAgNKXOC5edW12wgaydx8SSTwXKPYe6Fu1weJf60NIAJLz6A9p3L4L7+tuQfEBoHBoW7o2BaLzaoSqyDq61fZij3uxEWWOXtG40//W+wViaZ7BRx8Lj6j1SfoU2TBfr99/WWZyPKDg6Fgg59Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784010577; c=relaxed/simple; bh=/mlQ/0hPw7Zv87cKs9/mr9u2TDu1vLlp8F5QoahIUbM=; h=From:To:Cc:Subject:In-Reply-To:Date:Message-ID:References; b=IzPJb51HD3Jol5aWKV7H8XjtUQmY+RBey13FK6oGFFqhAm0Zq1eHtVTB/dZW/SW2/8/OTFKVud2N8ZLlaAbjnfCSQOFHBnhVzBy2YmmeNKJX3ZyGmeEKPFyGQEB/lZ62EfMCNvT7I0aO4KbaYQ+aGCUjxqjrUtRD0NfqRtQaHy4= 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=EJKSwdl7; arc=none smtp.client-ip=209.85.214.181 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="EJKSwdl7" Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-2ced3386430so5076945ad.1 for ; Mon, 13 Jul 2026 23:29:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1784010575; x=1784615375; darn=vger.kernel.org; h=references:message-id:date:in-reply-to:subject:cc:to:from:from:to :cc:subject:date:message-id:reply-to:content-type; bh=0NRVclgAStw8tC9C+ky0P+3DJf76U2sdBBGVotBh8Wg=; b=EJKSwdl7iRyrIpUAYqGjxlx5CASmMNTL6EsgjBbPKUubFt3GQR4BSp9mWcD/5rHj4N xpoieP0K3kp+3Torw1VGw7Rr+E4op4FkOg8n1aTVV8wobIDKCQbRkpKAzwuSCTuPaGOK Tbt+N7Mk/zauBZ2/l1JXUrJ3+7dosk6GubVr0c4UA9QeFJJriR3/1swt8k9TloYzTRNl yJIklChNMe+1GishWoe+HZShN2OABz+MILYMcU2SOWewQnl4kGV2OLxRXMNxnhrmooQ7 IOmnsKcZ/N3tS1M/JeJB4mEO1aXHKI9e7hfQM6OffgB94n6MMwXipvhSCyJ8dclXshvk eSBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1784010575; x=1784615375; h=references:message-id:date:in-reply-to:subject:cc:to:from:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=0NRVclgAStw8tC9C+ky0P+3DJf76U2sdBBGVotBh8Wg=; b=nN1DH8ytEDlm9lMutEtuL6M2lF2Xhw4p63wwR+7m4HUC3dLPyODSUAEEUC34y2eLUP Lo2+m9lhYR4/skvSJg9PJw52WSNl8zBEkz8bA+dfFBAr7NJLv8eWoF9PJll1kzrZA2wk JSQOYSpmPyz32CI5PVGA7hdmgi5lCMg5tidLAIbx2v81KTvqShHynW3MUxjotxUr8VpN SE8+0U9XR+AjomT4pzq58RO6YdL4vTQ4jV8FH4gpJbrIEOwq0nDXquTYkt+jhvZoqgSQ HON0Y4h0CYTbboz+hmJHcpQAgHoPVyP1pv0ymhgKtNxTApl0tDPLxYU/Oz1qHhZ15Ui+ YQcg== X-Forwarded-Encrypted: i=1; AHgh+Rq3kjcZesPXfDsmX3xO/mIzpHFQdMUKwI1zdez5RcIPZtAw1iOegq2uYJFINIqGu+RS1yfB9fAArAShxI0=@vger.kernel.org X-Gm-Message-State: AOJu0Yx4sFVVf5CGqj65BUgx20/NNisUH6Xd6wQPvT+BrqGfDfEShVIG o2sazkPkZsSZFBc9ej9oYCT7gFrBOqykb7KFXrpyQONavmu7WYgaWU1H X-Gm-Gg: AfdE7ck1t05gamLktcWTjiAetsW1NpY8pdLVKzUNRU5sbZvoAosJ3cBzI6aU5UiYcsD GdXw6qfGYZLazHEIKpteHLJOQbwVROvjSxTQ6x8GaFOV+oY9kLHpnDKnFyUqVFCcnKdYzYJETVd fc6E0XmqWiwNNYXtGW8SCcR8qGPBlH9TzcfBNiC5gSfG4C1VVkgp0pV6+PGbzYMMRESbQB6sFHn PymoqfctqrB/f7623pzJOrwmDKBRmr4yNwOzPbL72CUCIdacPc+XR+zJ0RIM4d13U6JLs3Y2V7a kzV3huOyS57YcTGcPjMjdr0i4m7aNoYLVTVVz08jgcyqebyhv1PpnnAmdEvCHupKpdlJQ0Nbexu xwh4W7IZ2EfNYZZdpLIxK/WJGo1ZApCNsYszIr0qTORawbyrAa13FVAtyVXqs3FaV+WqKcjuiAy bYkn4TjmEEdFk= X-Received: by 2002:a05:6a21:7018:b0:3bf:6edd:4dfb with SMTP id adf61e73a8af0-3c110009c5bmr11912286637.5.1784010575481; Mon, 13 Jul 2026 23:29:35 -0700 (PDT) Received: from pve-server ([49.205.216.49]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-311935fd091sm54624064eec.24.2026.07.13.23.29.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Jul 2026 23:29:32 -0700 (PDT) From: Ritesh Harjani (IBM) To: Joshua Hahn , linux-mm@kvack.org Cc: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , linux-kernel@vger.kernel.org, kernel-team@meta.com, Donet Tom Subject: Re: [PATCH] mm/memory-tiers: cache top tier nodes In-Reply-To: <20260706204507.98522-1-joshua.hahnjy@gmail.com> Date: Tue, 14 Jul 2026 10:17:00 +0530 Message-ID: References: <20260706204507.98522-1-joshua.hahnjy@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Joshua Hahn writes: > node_is_toptier() is called in a few hot paths: task_numa_fault(), > should_numa_migrate_memory(), folio_migrate_flags(), etc. Each call > takes an RCU read section and performs the tier distance check again. > > Tieredness for all nodes only changes on memory node hotplugs. Instead > of recomputing toptier nodes inside each of the hot paths above, compute > it only on memory node hotplug events and cache the results. > Did we observe this function "node_is_toptier()" in any of the perf reports? How much perf benefit we see with this, if at all? It will be worth adding that info to the commit msg. > Signed-off-by: Joshua Hahn > --- > mm/memory-tiers.c | 36 ++++++++++-------------------------- > 1 file changed, 10 insertions(+), 26 deletions(-) > > diff --git a/mm/memory-tiers.c b/mm/memory-tiers.c > index 54851d8a195b0..2e6e02ec1fce4 100644 > --- a/mm/memory-tiers.c > +++ b/mm/memory-tiers.c > @@ -71,6 +71,7 @@ bool folio_use_access_time(struct folio *folio) > > #ifdef CONFIG_NUMA_MIGRATION > static int top_tier_adistance; > +static nodemask_t toptier_nodes __read_mostly = NODE_MASK_ALL; > /* > * node_demotion[] examples: > * > @@ -276,27 +277,7 @@ static struct memory_tier *__node_get_memory_tier(int node) > #ifdef CONFIG_NUMA_MIGRATION > bool node_is_toptier(int node) > { > - bool toptier; > - pg_data_t *pgdat; > - struct memory_tier *memtier; > - > - pgdat = NODE_DATA(node); > - if (!pgdat) > - return false; > - > - rcu_read_lock(); > - memtier = rcu_dereference(pgdat->memtier); > - if (!memtier) { > - toptier = true; > - goto out; > - } > - if (memtier->adistance_start <= top_tier_adistance) > - toptier = true; > - else > - toptier = false; > -out: > - rcu_read_unlock(); > - return toptier; > + return node_isset(node, toptier_nodes); > } > > void node_get_allowed_targets(pg_data_t *pgdat, nodemask_t *targets) > @@ -497,19 +478,22 @@ static void establish_demotion_targets(void) > } > } > /* > - * Now build the lower_tier mask for each node collecting node mask from > - * all memory tier below it. This allows us to fallback demotion page > - * allocation to a set of nodes that is closer the above selected > - * preferred node. > + * A node stays toptier unless it belongs to a tier below > + * top_tier_adistance, while each tier's lower_tier_mask collects the > + * nodes of every tier below it so demotion page allocation can fall > + * back to nodes closer to the selected preferred node. > */ > + toptier_nodes = node_states[N_MEMORY]; > lower_tier = node_states[N_MEMORY]; > list_for_each_entry(memtier, &memory_tiers, list) { > + tier_nodes = get_memtier_nodemask(memtier); > + if (memtier->adistance_start > top_tier_adistance) > + nodes_andnot(toptier_nodes, toptier_nodes, tier_nodes); I looked into this and I don't see any major issue with this patch. However few things worth checking are: 1. From what I understood say if we add a pmem node as system ram, then due to the above logic, it will go through these transition states.. 0 -> 1 -> 0 This is because we update toptier_nodes to nodes_state[N_MEMORY], which means, pmem's nid becomes top tier and then we quickly transition that back to lower tier by clearing the mask. Instead maybe updating toptier_nodes in one shot at the end would avoid this intermediate state. 2. Also IIRC, after the nid is online, numa balancing for tiered memory can always work. And we store different values (I guess in folio->flags), depending upon whether the nid is toptier v/s lower tier. (_last_cpupid v/s folio last access time). It's worth checking that path once. ...So, I looked at it and I think the same transient discripancy (of whether the node is toptier or lower tier) is true even with the original code. So I don't think that it should be an issue. -ritesh > /* > * Keep removing current tier from lower_tier nodes, > * This will remove all nodes in current and above > * memory tier from the lower_tier mask. > */ > - tier_nodes = get_memtier_nodemask(memtier); > nodes_andnot(lower_tier, lower_tier, tier_nodes); > memtier->lower_tier_mask = lower_tier; > } > -- > 2.53.0-Meta