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

[Barry Song <21cnbao@gmail.com>]

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@oracle.com> wrote:
>
> * Matthew Wilcox <willy@infradead.org> [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.

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

>
> [1].  https://lore.kernel.org/all/20250514070820.51793-1-21cnbao@gmail.com/
>

Thanks
Barry