linux-kernel - Re: [PATCH v2] mm/demotion: print demotion targets

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <87cyt9yo1e.fsf@yhuang6-desk2.ccr.corp.intel.com>
Date: Wed, 07 Feb 2024 11:02:37 +0800
From: "Huang, Ying" <ying.huang@...el.com>
To: Li Zhijian <lizhijian@...itsu.com>
Cc: linux-mm@...ck.org,  Andrew Morton <akpm@...ux-foundation.org>,
  linux-kernel@...r.kernel.org,  "Aneesh Kumar K . V"
 <aneesh.kumar@...ux.ibm.com>
Subject: Re: [PATCH v2] mm/demotion: print demotion targets

Li Zhijian <lizhijian@...itsu.com> writes:

> 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 dmesg example with this patch is as follows:
> [    0.704860] Demotion targets for Node 0: null
> [    0.705456] Demotion targets for Node 1: null
> // node 2 is onlined
> [   32.259775] Demotion targets for Node 0: perferred: 2, fallback: 2
> [   32.261290] Demotion targets for Node 1: perferred: 2, fallback: 2
> [   32.262726] Demotion targets for Node 2: null
> // node 3 is onlined
> [   42.448809] Demotion targets for Node 0: perferred: 2, fallback: 2-3
> [   42.450704] Demotion targets for Node 1: perferred: 2, fallback: 2-3
> [   42.452556] Demotion targets for Node 2: perferred: 3, fallback: 3
> [   42.454136] Demotion targets for Node 3: null
> // node 4 is onlined
> [   52.676833] Demotion targets for Node 0: perferred: 2, fallback: 2-4
> [   52.678735] Demotion targets for Node 1: perferred: 2, fallback: 2-4
> [   52.680493] Demotion targets for Node 2: perferred: 4, fallback: 3-4
> [   52.682154] Demotion targets for Node 3: null
> [   52.683405] Demotion targets for Node 4: null
> // node 5 is onlined
> [   62.931902] Demotion targets for Node 0: perferred: 2, fallback: 2-5
> [   62.938266] Demotion targets for Node 1: perferred: 5, fallback: 2-5
> [   62.943515] Demotion targets for Node 2: perferred: 4, fallback: 3-4
> [   62.947471] Demotion targets for Node 3: null
> [   62.949908] Demotion targets for Node 4: null
> [   62.952137] Demotion targets for Node 5: perferred: 3, fallback: 3-4
>
> CC: "Huang, Ying" <ying.huang@...el.com>
> CC: Aneesh Kumar K.V <aneesh.kumar@...ux.ibm.com>
> Signed-off-by: Li Zhijian <lizhijian@...itsu.com>

LGTM, Thanks!

Reviewed-by: "Huang, Ying" <ying.huang@...el.com>

> ---
> V2:
> Regarding this requirement, we have previously discussed [1].
> The initial proposal involved introducing a new sys interface.
> However, due to concerns about potential changes and compatibility
> issues with the interface in the future, a consensus was not
> reached with the community. Therefore, this time, we are directly
> printing out the information.
>
> [1] https://lore.kernel.org/all/d1d5add8-8f4a-4578-8bf0-2cbe79b09989@fujitsu.com/
> ---
>  mm/memory-tiers.c | 24 +++++++++++++++++++++++-
>  1 file changed, 23 insertions(+), 1 deletion(-)
>
> diff --git a/mm/memory-tiers.c b/mm/memory-tiers.c
> index 5462d9e3c84c..4d3506a290b7 100644
> --- 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)
> +{
> +	int node;
> +
> +	for_each_node_state(node, N_MEMORY) {
> +		struct memory_tier *memtier = __node_get_memory_tier(node);
> +		nodemask_t preferred = node_demotion[node].preferred;
> +
> +		if (!memtier)
> +			continue;
> +
> +		if (nodes_empty(preferred))
> +			pr_info("Demotion targets for Node %d: null\n", node);
> +		else
> +			pr_info("Demotion targets for Node %d: preferred: %*pbl, fallback: %*pbl\n",
> +				node, nodemask_pr_args(&preferred),
> +				nodemask_pr_args(&memtier->lower_tier_mask));
> +	}
> +}
> +
>  /*
>   * Find an automatic demotion target for all memory
>   * nodes. Failing here is OK.  It might just indicate
> @@ -443,7 +463,7 @@ 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
> -	 * perferred node.
> +	 * preferred node.
>  	 */
>  	lower_tier = node_states[N_MEMORY];
>  	list_for_each_entry(memtier, &memory_tiers, list) {
> @@ -456,6 +476,8 @@ static void establish_demotion_targets(void)
>  		nodes_andnot(lower_tier, lower_tier, tier_nodes);
>  		memtier->lower_tier_mask = lower_tier;
>  	}
> +
> +	dump_demotion_targets();
>  }
>  
>  #else