linux-kernel - Re: [PATCH RFC v2] mm: memory-tiering: Fix PGPROMOTE

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <e71873b6-78ac-4555-a6a5-e9b5fb3f9112@fujitsu.com>
Date: Mon, 30 Jun 2025 02:11:30 +0000
From: "Zhijian Li (Fujitsu)" <lizhijian@...itsu.com>
To: "linux-mm@...ck.org" <linux-mm@...ck.org>, "Huang, Ying"
	<ying.huang@...el.com>
CC: "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, "Yasunori
 Gotou (Fujitsu)" <y-goto@...itsu.com>, Huang Ying
	<ying.huang@...ux.alibaba.com>, Ingo Molnar <mingo@...hat.com>, Peter
 Zijlstra <peterz@...radead.org>, Juri Lelli <juri.lelli@...hat.com>, Vincent
 Guittot <vincent.guittot@...aro.org>, Dietmar Eggemann
	<dietmar.eggemann@....com>, Steven Rostedt <rostedt@...dmis.org>, Ben Segall
	<bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>, Valentin Schneider
	<vschneid@...hat.com>, "lkp@...el.com" <lkp@...el.com>
Subject: Re: [PATCH RFC v2] mm: memory-tiering: Fix PGPROMOTE_CANDIDATE
 accounting

Hi,


On 25/06/2025 10:13, Li Zhijian wrote:
> V2:
> Fix compiling error # Reported by LKP
> 
> As Ying suggested, we need to assess whether this change causes regression.
> However, considering the stringent conditions this patch involves,
> properly evaluating it may be challenging, as the outcomes depend on your
> perspective. Much like in a zero-sum game, if someone benefits, another
> might lose.
> 
> If there are subsequent results, I will update them here.

I ran memhog + pmbench to evaluate the impact of the patch(3 runs [1] for each kernel).

The results show an approximate 4% performance increase in pmbench after applying this patch.

Average     pmbench-access            max-promotion-rate
Before:     7956805 pages/sec                168301 pages/sec
After:      8313666 pages/sec (+4.4%)        207149 pages/sec

The detailed logs are available at [2].

[1] https://github.com/zhijianli88/misc/blob/main/20250627/promotion-evaluation/reproduce.sh
[2] https://github.com/zhijianli88/misc/tree/main/20250627/promotion-evaluation

Thanks
Zhijian
> 
> Cc:lkp@...el.com
> Here, I hope to leverage the existing LKP benchmark to evaluate the
> potential impacts. The ideal evaluation conditions are:
> 1. Installed with DRAM + NVDIMM (which can be simulated).
> 2. NVDIMM is used as system RAM (configurable via daxctl).
> 3. Promotion is enabled (`echo 2 > /proc/sys/kernel/numa_balancing`).
> 
> Alternative:
> We can indeed eliminate the potential impact within
> pgdat_free_space_enough(), so that the rate limit behavior remains as
> before.
> 
> For instance, consider the following change:
>                  if (pgdat_free_space_enough(pgdat)) {
>                          /* workload changed, reset hot threshold */
>                          pgdat->nbp_threshold = 0;
> +                        pgdat->nbp_rl_nr_cand += nr;
>                          mod_node_page_state(pgdat, PGPROMOTE_CANDIDATE, nr);
>                          return true;
>                  }
> 
> RFC: