RE: [PATCH 0/3] mm/lru_gen: move lru_gen control interface from debugfs to procfs

wangzicheng
2025-12-01T08:14:17Z

>
> I strongly recommend separating this from your patchset. Avoid including
> unrelated changes in a single patchset.
>
Thank you for the clarification, separating it from our patchset makes sense.

Recall that imbalance file/anon generations is one of the reasons to move `lru_gen`
files out of the debugfs.

> MGLRU has a mechanism to ensure that file and anon pages can keep pace
> with each other. In the newest kernel, the minimum generation is 2. For
> example, if anon has only 2 generations left and we decide to reclaim anon
> folios, we will fall back to reclaiming file pages. Sometimes, this means that
> anon reclamation is insufficient while file pages are over-reclaimed.
>
> static int scan_folios(unsigned long nr_to_scan, struct lruvec *lruvec,
> struct scan_control *sc, int type, int tier,
> struct list_head *list) {
> ...
> if (get_nr_gens(lruvec, type) == MIN_NR_GENS)
> return 0;
> ...
> }
>
> This is probably not a bug, but this design can sometimes work suboptimally.
>

Yes, our patchset also aims to solve similar cases by proactive aging 2/3 gens.

> Regarding this issue, both Kairui (from the Linux server side, cc-ed) and I
> (from the Android side) have observed it. This should be addressed in
> MGLRU's code, and we already have kernel code for that. It is unrelated to
> your patchset, so you shouldn’t include so many unrelated changes in a
> single patchset.
>
> Please keep your patchset focused solely on whether the MGLRU proactive
> reclamation interface should be promoted to sysfs (LRU_GEN already has a
> folder in sysfs) instead of debugfs, if there is a v2.
>
> The following is quoted from
> `Documentation/admin-guide/mm/multigen_lru.rst`.
>
> Proactive reclaim
> -----------------
> Proactive reclaim induces page reclaim when there is no memory pressure. It
> usually targets cold pages only. E.g., when a new job comes in, the job
> scheduler wants to proactively reclaim cold pages on the server it selected,
> to improve the chance of successfully landing this new job.
>
> Users can write the following command to ``lru_gen`` to evict generations
> less than or equal to ``min_gen_nr``.
>
> ``- memcg_id node_id min_gen_nr [swappiness [nr_to_reclaim]]``
>
>
> >
> > See the case in the cover letter.
> > ```
> > memcg 54 /apps/some_app
> > node 0
> > 1 119804 0 85461
> > 2 119804 0 5
> > 3 119804 181719 18667
> > 4 1752 392 244
> > ```
> >
> >
> > Since the semantic gap between user/kernel space will always exist.
> > It would be great benefits for leaving some APIs for user hints, just
> > like mmadvise/userfault/para-virtualization.
>
> Nope. This is just an internal detail of MGLRU and shouldn’t be exposed as an
> interface.
> Hopefully, Kairui or I will send a patchset soon to address the balance issue
> between file and anon pages. For now, you can use `swappiness=201` as a
> temporary workaround. Take a look at bytedance's patchset.[1]
>
Sound great:), we are looking forward to it.

> > Exposing such hints to the kernel can help improve overall system
> performance.
>
> [1] https://lore.kernel.org/linux-
> mm/cover.1744169302.git.hezhongkun.hzk@bytedance.com/
>
And thank you for the `swappiness=201` workaround, we will research on it.

> Thanks
> Barry

Best,
Zicheng