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

[wangzicheng]

Hi Barry,

> Hi Liam,
> 
> I saw you mentioned me, so I just wanted to join in :-)
> 
> On Sat, Nov 29, 2025 at 12:16 AM Liam R. Howlett <Liam.Howlett@xxxxxxxxxx>
> wrote:
> >
> > * Matthew Wilcox <willy@xxxxxxxxxxxxx> [251128 10:16]:
> > > On Fri, Nov 28, 2025 at 10:53:12AM +0800, Zicheng Wang wrote:
> > > > Case study:
> > > > A widely observed issue on Android is that after application
> > > > launch,
> >
> > What do you mean by application launch?  What does this mean in the
> > kernel context?
> 
> I think there are two cases. First, a cold start: a new process is forked to
> launch the app. Second, when the app switches from background to
> foreground, for example when we bring it back to the screen after it has
> been running in the background.
> 
> In the first case, you reboot your phone and tap the YouTube icon to start
> the app (cold launch). In the second case, you are watching a video in
> YouTube, then switch to Facebook, and later tap the YouTube icon again to
> bring it from background to foreground.
> 
Thanks for the explain, that's exactly what I meant.  

Android lifecycle model isn't obvious outside the Android context. I’ll make that 
clearer in the next version.
> >
> > > > the oldest anon generation often becomes empty, and file pages are
> > > > over-reclaimed.
> > >
> > > You should fix the bug, not move the debug interface to procfs.  NACK.
> >
> > Barry recently sent an RFC [1] to affect LRU in the exit path for
> > Android.  This was proven incorrect by Johannes, iirc, in another
> > thread I cannot find (destroys performance of calling the same command).
> 
> My understanding is that affecting the LRU in the exit path is not generally
> correct, but it still highlights a requirement: Linux LRU needs a way to
> understand app-cycling behavior in an Android-like system.
> 
> >
> > These ideas seem both related as it points to a suboptimal LRU in the
> > Android ecosystem, at least.  It seems to stem from Androids life
> > (cycle) choices :)
> >
> > I strongly agree with Willy.  We don't want another userspace daemon
> > and/or interface, but this time to play with the LRU to avoid trying
> > to define and fix the problem.
> >
> > Do you know if this affects others or why it is android specific?
> 
> The behavior Zicheng probably wants is a proactive memory reclamation
> interface. For example, since each app may be in a different memcg, if an
> app has been in the background for a long time, he wants to reclaim its
> memory proactively rather than waiting until kswapd hits the watermarks.
> 
> This may help a newly launched app obtain memory more quickly, avoiding
> delays from reclamation, since a new app typically requires a substantial
> amount of memory.
> 
> Zicheng, please let me know if I’m misunderstanding anything.

Yes, but not least.

1. proactive memory reclaim: yes, that's we are after. 
When an app is swiped away and kept in the background and not use for a while, 
proactively reclaiming its memcg can help new foreground apps get memory 
faster (instead of paying the cost of direct reclaim).

2. Anon v.s. File: *bias more towards anonymous* pages for background apps.
With mglru, however, the oldest generations often contain almost no anon pages,
so simply tuning swappiness cannot achieve that -- reclaim will still clear file cache
in the old generations first.
To some extent, file caches are `over-reclaimed` in such senario, leading to a disaster
when user‑interaction threads get stuck in direct reclaim of anon pages.

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

> 
> >
> > [1].
> > https://lore.kernel.org/all/20250514070820.51793-1-21cnbao@xxxxxxxxx/
> >
> 
> Thanks
> Barry

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.
Exposing such hints to the kernel can help improve overall system performance.

Best,
Zicheng