Message-ID: <20251201071316.19607-1-zhongjinji@honor.com>
Date: Mon, 1 Dec 2025 15:13:16 +0800
From: zhongjinji <zhongjinji@...or.com>
To: <21cnbao@...il.com>
CC: <Liam.Howlett@...cle.com>, <akpm@...ux-foundation.org>,
	<axelrasmussen@...gle.com>, <corbet@....net>, <david@...hat.com>,
	<hannes@...xchg.org>, <linux-doc@...r.kernel.org>,
	<linux-kernel@...r.kernel.org>, <linux-mm@...ck.org>,
	<lorenzo.stoakes@...cle.com>, <mhocko@...nel.org>, <mhocko@...e.com>,
	<rppt@...nel.org>, <shakeel.butt@...ux.dev>, <surenb@...gle.com>,
	<vbabka@...e.cz>, <wangzicheng@...or.com>, <weixugc@...gle.com>,
	<willy@...radead.org>, <yuanchu@...gle.com>, <zhengqi.arch@...edance.com>
Subject: RE: [PATCH 0/3] mm/lru_gen: move lru_gen control interface from debugfs to procfs

> 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@...cle.com> wrote:
> >
> > * Matthew Wilcox <willy@...radead.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

Powered by blists - more mailing lists