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