Re: [PATCH v1 23/26] mm: vmscan: prepare for reparenting MGLRU folios
From: Qi Zheng
Date: Mon Dec 01 2025 - 22:05:14 EST
On 12/2/25 5:50 AM, Yuanchu Xie wrote:
On Mon, Dec 1, 2025 at 9:41 AM Qi Zheng <qi.zheng@xxxxxxxxx> wrote:
Warning 1) Here we increment max_seq but we skip updating mm_state->seq.
(try_to_inc_max_seq() iterates the mm list and update mm_state->seq after
an iteration, but since we directly call inc_max_seq(), we don't update it)
When mm_state->seq is more than one generation behind walk->seq, a warning is
triggered in iterate_mm_list():
VM_WARN_ON_ONCE(mm_state->seq + 1 < walk->max_seq);
The mm_state->seq is just to record the completion of a full traversal
of mm_list. If we simply delete this warning, it may cause this judgment
in iterate_mm_list to become invalid:
if (walk->seq <= mm_state->seq)
goto done;
So it seems we can manually increase mm_state->seq during reparenting to
avoid this warning.
Agreed, don't get rid of the warning as this check is supposed to make
stale walkers exit early.
OK, will incease mm_state->seq during reparenting in the next version.
However, we cannot directly call iterate_mm_list_nowalk() because we do
not want to reset mm_state->head and mm_state->tail to NULL. Otherwise,
we wouldn't be able to continue iterating over the mm_list.
From the original posting:
Of course, the same generation has different meanings in the parent and
child memcg, this will cause confusion in the hot and cold information of
folios. But other than that, this method is simple enough, the lru size
is correct, and there is no need to consider some concurrency issues (such
as lru_gen_del_folio()).
One way to solve this is to map generations based on
lrugen->timestamp, but of course this runs into the reading
folio->flags issue you described. I think the current method is a good
compromise, but the splicing of generations doesn't much make semantic
sense. It would be good to leave a comment somewhere in
__lru_gen_reparent_memcg to note this weirdness.
OK, will do.
Thanks!