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

[wangzicheng <wangzicheng@honor.com>]

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