Re: [PATCH 2/2] mm/ksm: add initialization helpers for scan_get_next_rmap_item()

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] mm/ksm: scan_begin_new_cycle() reorders lru_add_drain_all() at
  scan start
--

commit 82208b052cdf6d037a169e81cb68de5a2ad7f1fc
Author: Xu Xin (vivo) <xu.xin@linux.dev>

mm/ksm: add initialization helpers for scan_get_next_rmap_item()

This commit extracts the new scan cycle check and the first mm_slot lookup
from scan_get_next_rmap_item() into scan_begin_new_cycle() and
scan_get_first_mm().

[Severity: Low]
In mm/ksm.c, does moving lru_add_drain_all() into scan_begin_new_cycle()
change the execution order at the start of a scan cycle in
scan_get_next_rmap_item()?

Previously, when ksm_scan.mm_slot equaled &ksm_mm_head, advisor_start_scan()
and trace_ksm_start_scan() ran before lru_add_drain_all(). Calling
lru_add_drain_all() inside scan_begin_new_cycle() in the if condition runs
it before both calls, contrary to the commit message's statement that the
exact execution order is kept intact.

This reverses the relative order of the mm_lru_add_drain_all and
ksm_start_scan tracepoints. It also records advisor_ctx.start_scan via
ktime_get() in advisor_start_scan() only after lru_add_drain_all() finishes
draining per-CPU LRU caches, whereas scan_time_advisor() still includes the
ksmd CPU runtime spent inside lru_add_drain_all() via
task_sched_runtime(current).

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261112125754.176930-1-xu.xin@linux.dev?part=2