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

zhongjinji
2025-12-01T07:13:24Z

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

Yes, we need a mechanism for proactive memory reclamation that supports
proactive aging. Zicheng and I were just discussing this issue, and it
seems that supporting proactive aging during proactive memory reclamation
(such as reclamation of only anonymous pages) is a better approach, which
can be enabled by adding the parameter `force`. For example, the following
code, though it has other details to handle...

+static bool proactive_aging(struct lruvec *lruvec, int swappiness)
+{
+ int type;
+ bool should_age = false;
+
+ if (unlikely(sc->proactive && sc->proactive_force))
+ return false;
+
+ for_each_evictable_type(type, swappiness) {
+ if (get_nr_gens(lruvec, type) != MIN_NR_GENS)
+ continue;
+ should_age = true;
+ }
+ return should_age;
+}
/*
* For future optimizations:
* 1. Defer try_to_inc_max_seq() to workqueues to reduce latency for memcg
@@ -4845,6 +4860,8 @@ static long get_nr_to_scan(struct lruvec *lruvec, struct scan_control *sc, int s
if (mem_cgroup_below_min(sc->target_mem_cgroup, memcg))
return -1;

+ if (proactive_aging(lruvec, swappiness))
+ goto aging;
success = should_run_aging(lruvec, max_seq, swappiness, &nr_to_scan);

/* try to scrape all its memory if this memcg was deleted */
@@ -4856,7 +4873,7 @@ static long get_nr_to_scan(struct lruvec *lruvec, struct scan_control *sc, int s
/* try to get away with not aging at the default priority */
if (!success || sc->priority == DEF_PRIORITY)
return nr_to_scan >> sc->priority;
-
+aging:
/* stop scanning this lruvec as it's low on cold folios */
return try_to_inc_max_seq(lruvec, max_seq, swappiness, false) ? -1 : 0;
}

> 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