Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
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


      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