[PATCH 1/2] mm/vmscan: Accumulate nr_demoted for accurate demotion statistics

[PATCH 1/2] mm/vmscan: Accumulate nr_demoted for accurate demotion statistics

[Li Zhijian]

In the shrink_folio_list() function, demote_folio_list() can be called
multiple times, which can lead to inaccurate demotion statistics if the
number of demoted pages is not accumulated correctly.

Accumulate the nr_demoted count across multiple calls to
demote_folio_list(), ensuring accurate reporting of demotion statistics.

Fixes: f77f0c751478 ("mm,memcg: provide per-cgroup counters for NUMA balancing operations")
Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
---
 mm/vmscan.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 9a859b7d18d7..430d580e37dd 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1522,7 +1522,7 @@ static unsigned int shrink_folio_list(struct list_head *folio_list,
 	/* 'folio_list' is always empty here */
 
 	/* Migrate folios selected for demotion */
-	stat->nr_demoted = demote_folio_list(&demote_folios, pgdat);
+	stat->nr_demoted += demote_folio_list(&demote_folios, pgdat);
 	nr_reclaimed += stat->nr_demoted;
 	/* Folios that could not be demoted are still in @demote_folios */
 	if (!list_empty(&demote_folios)) {
-- 
2.44.0

[PATCH 2/2] mm/vmscan: Fix pgdemote_* accounting with lru_gen_enabled

[Li Zhijian]

Commit f77f0c751478 ("mm,memcg: provide per-cgroup counters for NUMA balancing operations")
moved the accounting of PGDEMOTE_* statistics to shrink_inactive_list().
However, shrink_inactive_list() is not called when lrugen_enabled is true,
leading to incorrect demotion statistics despite actual demotion events
occurring.

Add the PGDEMOTE_* accounting in evict_folios(), ensuring that demotion
statistics are correctly updated regardless of the lru_gen_enabled state.
This fix is crucial for systems that rely on accurate NUMA balancing
metrics for performance tuning and resource management.

Fixes: f77f0c751478 ("mm,memcg: provide per-cgroup counters for NUMA balancing operations")
Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
---
 mm/vmscan.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 430d580e37dd..f2d279de06c4 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -4642,6 +4642,8 @@ static int evict_folios(struct lruvec *lruvec, struct scan_control *sc, int swap
 		reset_batch_size(walk);
 	}
 
+	__mod_lruvec_state(lruvec, PGDEMOTE_KSWAPD + reclaimer_offset(),
+			   stat.nr_demoted);
 	item = PGSTEAL_KSWAPD + reclaimer_offset();
 	if (!cgroup_reclaim(sc))
 		__count_vm_events(item, reclaimed);
-- 
2.44.0

Re: [PATCH 1/2] mm/vmscan: Accumulate nr_demoted for accurate demotion statistics

[Kaiyang Zhao]

On Fri, Jan 10, 2025 at 08:21:32PM +0800, Li Zhijian wrote:
> In the shrink_folio_list() function, demote_folio_list() can be called
> multiple times, which can lead to inaccurate demotion statistics if the
> number of demoted pages is not accumulated correctly.

It looks like demotion will only be attempted once. On the second pass,
do_demote_pass will be false, demote_folios will be empty and
demote_folio_list() will do nothing. But I guess there is no harm in
making nr_demoted  an accumulation for less confusion in the future...

Re: [PATCH 1/2] mm/vmscan: Accumulate nr_demoted for accurate demotion statistics

[Zhijian Li (Fujitsu)]

[-- Attachment #1: Type: text/plain, Size: 1457 bytes --]

＞ It looks like demotion will only be attempted once. On the second pass,
do_demote_pass will be false, demote_folios will be empty and
demote_folio_list() will do nothing. But I guess there is no harm in
making nr_demoted  an accumulation for less confusion in the future...


Emm, after checked the code again, it seems you are right. But this can not explain why i got inaccurate demotion statistics from /proc/vmstat compared to the value i counted in the code myself days ago.

thanks for your feedback, i will take a look next week.

Get Outlook for Android<https://aka.ms/AAb9ysg>

________________________________
发件人: Kaiyang Zhao <kaiyang2@cs.cmu.edu>
发送时间: 2025年1月10日星期五 20:50
收件人: Li, Zhijian/李 智坚
抄送: linux-mm@kvack.org; Andrew Morton; linux-kernel@vger.kernel.org
主题: Re: [PATCH 1/2] mm/vmscan: Accumulate nr_demoted for accurate demotion statistics

On Fri, Jan 10, 2025 at 08:21:32PM +0800, Li Zhijian wrote:
> In the shrink_folio_list() function, demote_folio_list() can be called
> multiple times, which can lead to inaccurate demotion statistics if the
> number of demoted pages is not accumulated correctly.

It looks like demotion will only be attempted once. On the second pass,
do_demote_pass will be false, demote_folios will be empty and
demote_folio_list() will do nothing. But I guess there is no harm in
making nr_demoted  an accumulation for less confusion in the future...


[-- Attachment #2: Type: text/html, Size: 2605 bytes --]

Re: [PATCH 1/2] mm/vmscan: Accumulate nr_demoted for accurate demotion statistics

[Zhijian Li (Fujitsu)]

[-- Attachment #1: Type: text/plain, Size: 2185 bytes --]

> Emm, after checked the code again, it seems you are right. But this can not explain why i got inaccurate demotion statistics from /proc/vmstat compared to the value i counted in the code myself days ago.

Well... I know what was going on, the second pass will override stat-＞nr_demoted to be *zero* that makes the first try  stat-＞nr_demoted got lost.




Get Outlook for Android<https://aka.ms/AAb9ysg>

________________________________
发件人: Li, Zhijian/李 智坚 <lizhijian@fujitsu.com>
发送时间: 2025年1月10日星期五 22:20
收件人: Kaiyang Zhao
抄送: linux-mm@kvack.org; Andrew Morton; linux-kernel@vger.kernel.org
主题: Re: [PATCH 1/2] mm/vmscan: Accumulate nr_demoted for accurate demotion statistics

＞ It looks like demotion will only be attempted once. On the second pass,
do_demote_pass will be false, demote_folios will be empty and
demote_folio_list() will do nothing. But I guess there is no harm in
making nr_demoted  an accumulation for less confusion in the future...


Emm, after checked the code again, it seems you are right. But this can not explain why i got inaccurate demotion statistics from /proc/vmstat compared to the value i counted in the code myself days ago.

thanks for your feedback, i will take a look next week.

Get Outlook for Android<https://aka.ms/AAb9ysg>

________________________________
发件人: Kaiyang Zhao <kaiyang2@cs.cmu.edu>
发送时间: 2025年1月10日星期五 20:50
收件人: Li, Zhijian/李 智坚
抄送: linux-mm@kvack.org; Andrew Morton; linux-kernel@vger.kernel.org
主题: Re: [PATCH 1/2] mm/vmscan: Accumulate nr_demoted for accurate demotion statistics

On Fri, Jan 10, 2025 at 08:21:32PM +0800, Li Zhijian wrote:
> In the shrink_folio_list() function, demote_folio_list() can be called
> multiple times, which can lead to inaccurate demotion statistics if the
> number of demoted pages is not accumulated correctly.

It looks like demotion will only be attempted once. On the second pass,
do_demote_pass will be false, demote_folios will be empty and
demote_folio_list() will do nothing. But I guess there is no harm in
making nr_demoted  an accumulation for less confusion in the future...



[-- Attachment #2: Type: text/html, Size: 4308 bytes --]

Re: [PATCH 1/2] mm/vmscan: Accumulate nr_demoted for accurate demotion statistics

[Kaiyang Zhao]

> Well... I know what was going on, the second pass will override stat-＞nr_demoted to be *zero* that makes the first try  stat-＞nr_demoted got lost.
 
Ah you are right. This is a bug when demotion partially succeeds in
the first pass. Thanks for catching it.

Acked-by: Kaiyang Zhao <kaiyang2@cs.cmu.edu>

Re: [PATCH 2/2] mm/vmscan: Fix pgdemote_* accounting with lru_gen_enabled

[Yu Zhao]

On Fri, Jan 10, 2025 at 5:20 AM Li Zhijian <lizhijian@fujitsu.com> wrote:
>
> Commit f77f0c751478 ("mm,memcg: provide per-cgroup counters for NUMA balancing operations")
> moved the accounting of PGDEMOTE_* statistics to shrink_inactive_list().
> However, shrink_inactive_list() is not called when lrugen_enabled is true,
> leading to incorrect demotion statistics despite actual demotion events
> occurring.
>
> Add the PGDEMOTE_* accounting in evict_folios(), ensuring that demotion
> statistics are correctly updated regardless of the lru_gen_enabled state.
> This fix is crucial for systems that rely on accurate NUMA balancing
> metrics for performance tuning and resource management.
>
> Fixes: f77f0c751478 ("mm,memcg: provide per-cgroup counters for NUMA balancing operations")
> Signed-off-by: Li Zhijian <lizhijian@fujitsu.com>
> ---
>  mm/vmscan.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/mm/vmscan.c b/mm/vmscan.c
> index 430d580e37dd..f2d279de06c4 100644
> --- a/mm/vmscan.c
> +++ b/mm/vmscan.c
> @@ -4642,6 +4642,8 @@ static int evict_folios(struct lruvec *lruvec, struct scan_control *sc, int swap
>                 reset_batch_size(walk);
>         }
>
> +       __mod_lruvec_state(lruvec, PGDEMOTE_KSWAPD + reclaimer_offset(),
> +                          stat.nr_demoted);

The mm-hotfixes-stable already has the same fix from Donet:
https://lore.kernel.org/linux-mm/20250109060540.451261-1-donettom@linux.ibm.com/

Andew, can you please drop this one from mm-unstable so that we won't
increment the counter twice?

Thanks!