[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ti7h5cbrg5s3zf7surof3zmxb6supnl34x7hsbziqutm7r2laf@zuunap5hwsbx>
Date: Fri, 28 Nov 2025 11:13:37 -0500
From: "Liam R. Howlett" <Liam.Howlett@...cle.com>
To: Matthew Wilcox <willy@...radead.org>
Cc: Zicheng Wang <wangzicheng@...or.com>, akpm@...ux-foundation.org,
hannes@...xchg.org, david@...hat.com, axelrasmussen@...gle.com,
yuanchu@...gle.com, mhocko@...nel.org, zhengqi.arch@...edance.com,
shakeel.butt@...ux.dev, lorenzo.stoakes@...cle.com, weixugc@...gle.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
Subject: Re: [PATCH 0/3] mm/lru_gen: move lru_gen control interface from
debugfs to procfs
* 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?
> > 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).
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?
[1]. https://lore.kernel.org/all/20250514070820.51793-1-21cnbao@gmail.com/
Powered by blists - more mailing lists