From: Chen Ridong When enabling vmscan tracing, it is observed that nr_requested is always 4096, which is confusing. mm_vmscan_lru_isolate: classzone=3 order=0 nr_requested=4096 ... mm_vmscan_lru_isolate: classzone=3 order=0 nr_requested=4096 ... mm_vmscan_lru_isolate: classzone=3 order=0 nr_requested=4096 ... mm_vmscan_lru_isolate: classzone=3 order=0 nr_requested=4096 ... mm_vmscan_lru_isolate: classzone=3 order=0 nr_requested=4096 ... mm_vmscan_lru_isolate: classzone=3 order=0 nr_requested=4096 ... mm_vmscan_lru_isolate: classzone=3 order=0 nr_requested=4096 ... This is because it prints MAX_LRU_BATCH, which is meaningless as it's a constant. To fix this, modify it to print nr_to_scan as isolate_lru_folios does. Fixes: 8c2214fc9a47 ("mm: multi-gen LRU: reuse some legacy trace events") Signed-off-by: Chen Ridong --- mm/vmscan.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/mm/vmscan.c b/mm/vmscan.c index fddd168a9737..8cfafd50a7a8 100644 --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -4601,7 +4601,7 @@ static int scan_folios(unsigned long nr_to_scan, struct lruvec *lruvec, count_memcg_events(memcg, item, isolated); count_memcg_events(memcg, PGREFILL, sorted); __count_vm_events(PGSCAN_ANON + type, isolated); - trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, MAX_LRU_BATCH, + trace_mm_vmscan_lru_isolate(sc->reclaim_idx, sc->order, nr_to_scan, scanned, skipped, isolated, type ? LRU_INACTIVE_FILE : LRU_INACTIVE_ANON); if (type == LRU_GEN_FILE) -- 2.34.1