Re: [PATCH RFC v2] mm: memory-tiering: Fix PGPROMOTE_CANDIDATE accounting
From: Zhijian Li (Fujitsu)
Date: Sun Jun 29 2025 - 22:12:54 EST
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@xxxxxxxxx
> 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: