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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <66c62243a510421db938235a99a242bf@honor.com>
Date: Mon, 1 Dec 2025 08:14:14 +0000
From: wangzicheng <wangzicheng@...or.com>
To: Barry Song <21cnbao@...il.com>
CC: "Liam R. Howlett" <Liam.Howlett@...cle.com>, Matthew Wilcox
	<willy@...radead.org>, "akpm@...ux-foundation.org"
	<akpm@...ux-foundation.org>, "hannes@...xchg.org" <hannes@...xchg.org>,
	"david@...hat.com" <david@...hat.com>, "axelrasmussen@...gle.com"
	<axelrasmussen@...gle.com>, "yuanchu@...gle.com" <yuanchu@...gle.com>,
	"mhocko@...nel.org" <mhocko@...nel.org>, "zhengqi.arch@...edance.com"
	<zhengqi.arch@...edance.com>, "shakeel.butt@...ux.dev"
	<shakeel.butt@...ux.dev>, "lorenzo.stoakes@...cle.com"
	<lorenzo.stoakes@...cle.com>, "weixugc@...gle.com" <weixugc@...gle.com>,
	"vbabka@...e.cz" <vbabka@...e.cz>, "rppt@...nel.org" <rppt@...nel.org>,
	"surenb@...gle.com" <surenb@...gle.com>, "mhocko@...e.com" <mhocko@...e.com>,
	"corbet@....net" <corbet@....net>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, wangtao
	<tao.wangtao@...or.com>, wangzhen 00021541 <wangzhen5@...or.com>, "zhongjinji
 00025326" <zhongjinji@...or.com>, Kairui Song <ryncsn@...il.com>
Subject: RE: [PATCH 0/3] mm/lru_gen: move lru_gen control interface from
 debugfs to procfs

> 
> 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@...edance.com/
> 
And thank you for the `swappiness=201` workaround, we will research on it.

> Thanks
> Barry

Best,
Zicheng