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

[Ridong Chen]

On 7/16/2026 1:55 AM, T.J. Mercier wrote:
> On Tue, Jul 14, 2026 at 5:15 AM Zicheng Wang <wangzicheng@xxxxxxxxx> 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=65bd7ab941a709bf049871406981022b988e1721;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