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

Ridong Chen <[email protected]>
Newsgroups org.kernel.vger.cgroups,org.kernel.vger.linux-doc,org.kernel.vger.linux-kernel,org.kvack.linux-mm
Message-ID <[email protected]>

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=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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.