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

[Ridong Chen <ridong.chen@linux.dev>]

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