Received-SPF: pass (google.com: domain of linux-kernel+bounces-55593-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Tue, 6 Feb 2024 12:23:44 -0800
From: Andrew Morton <akpm@linux-foundation.org>
To: Li Zhijian <lizhijian@fujitsu.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, "Huang, Ying"
 <ying.huang@intel.com>, "Aneesh Kumar K . V" <aneesh.kumar@linux.ibm.com>
Subject: Re: [PATCH v2] mm/demotion: print demotion targets
Message-Id: <20240206122344.4cd39c6ebb37871912c459fe@linux-foundation.org>
In-Reply-To: <20240206020151.605516-1-lizhijian@fujitsu.com>
References: <20240206020151.605516-1-lizhijian@fujitsu.com>
Precedence: bulk
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit

On Tue,  6 Feb 2024 10:01:51 +0800 Li Zhijian <lizhijian@fujitsu.com> wrote:

> Currently, when a demotion occurs, it will prioritize selecting a node
> from the preferred targets as the destination node for the demotion. If
> the preferred node does not meet the requirements, it will try from all
> the lower memory tier nodes until it finds a suitable demotion destination
> node or ultimately fails.
> 
> However, the demotion target information isn't exposed to the users,
> especially the preferred target information, which relies on more factors.
> This makes users hard to understand the exact demotion behavior.
> 
> Rather than having a new sys interface to expose this information,
> printing directly to kernel messages, just like the current page
> allocation fallback order does.
>
> ...
>
> --- a/mm/memory-tiers.c
> +++ b/mm/memory-tiers.c
> @@ -359,6 +359,26 @@ static void disable_all_demotion_targets(void)
>  	synchronize_rcu();
>  }
>  
> +static void dump_demotion_targets(void)

Unrelated, but...  establish_demotion_targets() should be __meminit, so
dump_demotion_targets() could also be __meminit.