From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out-185.mta0.migadu.com (out-185.mta0.migadu.com [91.218.175.185]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9EBAC3A0B29 for ; Fri, 6 Feb 2026 18:52:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.185 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770403936; cv=none; b=NwjzQPEy8thY71ZJ69Sl++vi+DXuOLLBs99AzbRnEgK8JnSE9WpgcWDdp5Fh101FeRT57N4gA1JRUU3kcbPWec1yFMYbwamJsZOUJ3ARajl+QmSOwgXJVMs0cvtNhlT+Dx6CyIIbCrcIQbWccoXo/I9HHFGTffb0MR5io+vfGVY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770403936; c=relaxed/simple; bh=f63dsk0wa9kOaQro3oFzPnzpavve7SChOom4RDIoMjs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=sR7um2xW3EtpCXu7l8ze0HC3xPb12AiR0T+YBfv7RqWMwB+b/rgSKzxqUJFsG9Sbo6x8vfHr7ZaWXdQrRvg60ZqJP1A5KzB+GgyCNHg3arLD07YnNzhx/2LkjCVjMkBDHVgVw7pw/3eGZ32M6MHGjqQSUMM6CctmpmcVuRlB00A= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=sitd4Vye; arc=none smtp.client-ip=91.218.175.185 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="sitd4Vye" Date: Fri, 6 Feb 2026 10:52:07 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1770403933; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=r7mumZbXKpp+UcC6LYCZ5Q8LNGAoHw/22vUr8wOhvA4=; b=sitd4Vye4V/h7qHTBkS38bDEsI6P/BMUzZU1dGeEAQ7LW0tF0D+Xry1ug3ppPBmOqyXrwC D/QEjYc8d0wumdHpoeTnUJMnl6As6win53CMiNTMMfcYMZmcmkNwIbLcCqTZl7FzJM52eF Bwl6eGOB4b2Q1AbfDVxoZfR38JQX/mQ= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Shakeel Butt To: Bing Jiao Cc: Andrew Morton , David Hildenbrand , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Axel Rasmussen , Yuanchu Xie , Wei Xu , Johannes Weiner , Qi Zheng , Gregory Price , Joshua Hahn , muchun.song@linux.dev, roman.gushchin@linux.dev, tj@kernel.org, longman@redhat.com, chenridong@huaweicloud.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, cgroups@vger.kernel.org Subject: Re: [PATCH v9 2/2] mm/vmscan: select the closest perferred node in demote_folio_list() Message-ID: References: <20260114070053.2446770-1-bingjiao@google.com> <20260114205305.2869796-1-bingjiao@google.com> <20260114205305.2869796-3-bingjiao@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260114205305.2869796-3-bingjiao@google.com> X-Migadu-Flow: FLOW_OUT On Wed, Jan 14, 2026 at 08:53:03PM +0000, Bing Jiao wrote: > The preferred demotion node (migration_target_control.nid) should be the > one closest to the source node to minimize migration latency. Currently, > a discrepancy exists where demote_folio_list() randomly selects an allowed > node if the preferred node from next_demotion_node() is not set in > mems_effective. > > To address it, update next_demotion_node() to select a preferred target > against allowed nodes; and to return the closest demotion target if all > preferred nodes are not in mems_effective via next_demotion_node(). > > It ensures that the preferred demotion target is consistently the closest > available node to the source node. > > Signed-off-by: Bing Jiao One nit below: Acked-by: Shakeel Butt [...] > @@ -320,16 +320,17 @@ void node_get_allowed_targets(pg_data_t *pgdat, nodemask_t *targets) > /** > * next_demotion_node() - Get the next node in the demotion path > * @node: The starting node to lookup the next node > + * @allowed_mask: The pointer to allowed node mask > * > * Return: node id for next memory node in the demotion path hierarchy > * from @node; NUMA_NO_NODE if @node is terminal. This does not keep > * @node online or guarantee that it *continues* to be the next demotion > * target. > */ > -int next_demotion_node(int node) > +int next_demotion_node(int node, const nodemask_t *allowed_mask) > { > struct demotion_nodes *nd; > - int target; > + nodemask_t mask; > > if (!node_demotion) > return NUMA_NO_NODE; > @@ -344,6 +345,10 @@ int next_demotion_node(int node) > * node_demotion[] reads need to be consistent. > */ > rcu_read_lock(); > + /* Filter out nodes that are not in allowed_mask. */ > + nodes_and(mask, nd->preferred, *allowed_mask); > + rcu_read_unlock(); > + > /* > * If there are multiple target nodes, just select one > * target node randomly. > @@ -356,10 +361,16 @@ int next_demotion_node(int node) > * caching issue, which seems more complicated. So selecting > * target node randomly seems better until now. > */ > - target = node_random(&nd->preferred); > - rcu_read_unlock(); > + if (!nodes_empty(mask)) > + return node_random(&mask); > > - return target; > + /* > + * Preferred nodes are not in allowed_mask. Filp bits in Filp -> Flip > + * allowed_mask as used node mask. Then, use it to get the > + * closest demotion target. > + */ > + nodes_complement(mask, *allowed_mask); > + return find_next_best_node(node, &mask); > } >