From: Aneesh Kumar K.V <aneesh.kumar@kernel.org>
To: Joshua Hahn <joshua.hahnjy@gmail.com>, linux-mm@kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
linux-kernel@vger.kernel.org, kernel-team@meta.com
Subject: Re: [PATCH] mm/memory-tiers: cache top tier nodes
Date: Sun, 12 Jul 2026 14:13:24 +0530 [thread overview]
Message-ID: <yq5apl0sk383.fsf@kernel.org> (raw)
In-Reply-To: <20260706204507.98522-1-joshua.hahnjy@gmail.com>
Joshua Hahn <joshua.hahnjy@gmail.com> 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.
>
> Signed-off-by: Joshua Hahn <joshua.hahnjy@gmail.com>
> ---
> 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];
>
Won't this result in a larger window where every node_is_toptier() call
can return an incorrect result? This change would make every memory node
a top-tier node until the loop below clears them from the toptier_nodes
nodemask.
I assume an incorrect result from node_is_toptier() is not too bad, but
is the performance impact large enough to make this change?
> 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);
> /*
> * 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
-aneesh
prev parent reply other threads:[~2026-07-12 8:43 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-06 20:45 [PATCH] mm/memory-tiers: cache top tier nodes Joshua Hahn
2026-07-12 8:43 ` Aneesh Kumar K.V [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=yq5apl0sk383.fsf@kernel.org \
--to=aneesh.kumar@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=joshua.hahnjy@gmail.com \
--cc=kernel-team@meta.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox