Re: [RFC v2 0/3] mm/mglru: proactive aging via memory.aging
"T.J. Mercier" <[email protected]>
| Newsgroups | org.kernel.vger.cgroups,org.kernel.vger.linux-doc,org.kernel.vger.linux-kernel,org.kvack.linux-mm |
|---|---|
| Message-ID | <CABdmKX3y841t4Oqg3RRHTGXWP-LMMSi_exDuxAc4jR9v9ChD2g@mail.gmail.com> |
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.