> 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=65bd7ab941a70
> 9bf049871406981022b988e1721;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.

Hi T.J.,

Thanks for the reference.

We know Android reclaims the entire workingset and freezes the cgroup
on backgrounding (we discussed this at LSF/MM/BPF 2026, if I recall).
We are concerned about performance: that means a subsequent hot start
has to re-fault the whole set, which may increase IO, CPU, and power
cost. We would prefer a reclaim ratio tuned per SoC, trading memory
headroom against hot-start latency.

Proactive aging is what makes that workable: age first so anonymous
pages become reclaimable, then reclaim them while retaining the file
cache.

fg->bg is a simple and effective heuristic. Proactive aging is useful
beyond it: on file-cache-bound servers (fio random-read +31.8% in our
measurements), and likely in other Android scenarios we have not yet
explored.
  
Best,
Zicheng