linux-kernel - [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-next>] [day] [month] [year] [list]

Message-ID: <20251128025315.3520689-1-wangzicheng@honor.com>
Date: Fri, 28 Nov 2025 10:53:12 +0800
From: Zicheng Wang <wangzicheng@...or.com>
To: <akpm@...ux-foundation.org>, <hannes@...xchg.org>, <david@...hat.com>,
	<axelrasmussen@...gle.com>, <yuanchu@...gle.com>
CC: <mhocko@...nel.org>, <zhengqi.arch@...edance.com>,
	<shakeel.butt@...ux.dev>, <lorenzo.stoakes@...cle.com>, <weixugc@...gle.com>,
	<Liam.Howlett@...cle.com>, <vbabka@...e.cz>, <rppt@...nel.org>,
	<surenb@...gle.com>, <mhocko@...e.com>, <corbet@....net>,
	<linux-mm@...ck.org>, <linux-doc@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, Zicheng Wang <wangzicheng@...or.com>
Subject: [PATCH 0/3] mm/lru_gen: move lru_gen control interface from debugfs to procfs

This patchset moves the lru_gen control interface from debugfs to procfs.
Exposing the interface enables the capabilities for *commercial products*
such as Android to proactive aging and reclaim.

Two main reasons:
1. The MGLRU reaches the stage where its control interface can be
consideres product-ready, not just for experiments or debugging.
In specific scenarios, proactive aging with reclaim can improve
overall system performance.
2. Commercial products like Android prohibit mounting debugfs for
security reasons (selinux neverallow). Without moving the interface
to procfs, Android cannot utilize lru_gen.

Case study:
A widely observed issue on Android is that after application launch,
the oldest anon generation often becomes empty, and file pages
are over-reclaimed.

In Android, each application owns its own memcg. When an app is swiped
away seconds or minutes after (cold) launch, it will be frozen and
part of its memory is proactively reclaimed.
At this time, both file pages and anonymous pages are temporarily unused,
while the system load is also typically low, making it an ideal time to
prefer reclaiming anon pages while retaining file cache.

Keeping more file cache benefits the system in multiple ways:
1. The device can retain a larger page cache, reducing IO.
2. When memory is tight, evicting clean cache pages is fast.
2. Super-apps such as camera benefit from reducing the chance of
slow direct reclaim on the critical startup path.

Experiments:

- after cold launch
```
Kernel version v6.6
memcg    54 /apps/some_app
node     0
1     119804          0       85461
2     119804          0           5
3     119804     181719       18667
4       1752        392         244

Kernel version v6.12
memcg    84 /apps/some_app
node     0
1      38428          0       16424
2      38428      24307       14997
3      38428     126529       56452
4      37980         27           1
```

- proactive aging 2/3 times
```
Kernel version v6.6
memcg    54 /apps/some_app
 node     0
          3     172432     102532      103441
          4      54380      74803         854
          5      28892       6496         229
          6       1588         26           0  

Kernel version v6.12
memcg    84 /apps/some_app
 node     0
          3     819624      98726      166045
          4     819176      14849        1543
          5      40000      41328        7633
          6        960          0           0     
```

In continuous app-launch scenarios (e.g., After boot, retail demo
loops, tech review testing), our measurements show: v6.6
1. Available memory improves by 400–800 MB.
2. Direct reclaim frequency and latency drop by more than 24%.
3. memavailable/cached levels aligns with traditional LRU.

Summary of average available memory (MB):
mglru without proactive aging: 6060
mglru with proactive aging test1~3: 6988/6432/6837
traditional LRU: 6982

Camera direct reclaim (10-run average):
mglru without aging: 1050 events / 460 ms
mglru with aging: 789 events / 316 ms
(25% fewer events, 31% lower latency)

Signed-off-by: Zicheng Wang <wangzicheng@...or.com>

 Documentation/admin-guide/mm/multigen_lru.rst | 19 ++++++++++
 mm/Kconfig                                    | 10 +++++
 mm/vmscan.c                                   | 37 ++++++++++++++++++-
 3 files changed, 64 insertions(+), 2 deletions(-)

-- 
2.25.1