diff mbox series

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

Message ID 20250110122133.423481-1-lizhijian@fujitsu.com (mailing list archive)
State New
Headers show
Series [1/2] mm/vmscan: Accumulate nr_demoted for accurate demotion statistics | expand

Commit Message

Zhijian Li (Fujitsu) Jan. 10, 2025, 12:21 p.m. UTC
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(-)

Comments

Kaiyang Zhao Jan. 10, 2025, 12:49 p.m. UTC | #1
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...
Zhijian Li (Fujitsu) Jan. 10, 2025, 2:19 p.m. UTC | #2
> 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>
Zhijian Li (Fujitsu) Jan. 10, 2025, 2:24 p.m. UTC | #3
> 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>
Kaiyang Zhao Jan. 10, 2025, 3:24 p.m. UTC | #4
> 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>
diff mbox series

Patch

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)) {