RE: [RFC v2 0/3] mm/mglru: proactive aging via memory.aging

> On 7/16/2026 1:55 AM, T.J. Mercier wrote:
> > On Tue, Jul 14, 2026 at 5:15 AM Zicheng Wang <[email protected]>
> wrote:
> >> The benefit is workload-dependent: file-cache-bound servers gain from
> >> aging, anon-bound servers do not, so no kernel default is correct for
> >> all.  The kernel also cannot know when to age: on Android the right
> >> moment is the foreground-to-background transition, when the app's
> pages
> >> are cold but their PTE accessed bits are still accurate from foreground
> >> execution, a framework concept.
> >
> > When an app transitions and becomes cached, we attempt to reclaim its
> > entire workingset. We basically cat memory.current > memory.reclaim
> > and freeze the cgroup.
> > https://cs.android.com/android/platform/superproject/+/android-latest-
> release:system/core/libprocessgroup/task_profiles.cpp;drc=65bd7ab941a70
> 9bf049871406981022b988e1721;l=706
> >
> > File / anon balance vs hotness and generational placement doesn't
> > matter in that scenario because we want to get rid of all of it. So I
> > don't really understand how you'd want to use an aging knob.
> >
> 
> When the app becomes the foreground app again, reclaiming all of its
> background memcg memory may increase refault data, which may in turn
> slow down warm-launch performance.
> 
> --
> Best regards
> Ridong
> 

Hi Ridong,

Agreed. That is the motivation for proactive aging: keep the file cache
and shed cold anonymous pages, so there is less to refault on the
next launch and scroll janks. 

Best,
Zicheng