Re: [LSF/MM/BPF TOPIC] MGLRU on Android: Real-World Problems and Challenges

["T.J. Mercier" <tjmercier@google.com>]

On Thu, Feb 26, 2026 at 2:11 PM Yuanchu Xie <yuanchu@google.com> wrote:
>
> Hi Barry and Zicheng,
>
> On Tue, Feb 24, 2026 at 2:23 PM Barry Song <21cnbao@gmail.com> wrote:
> >
> > On Tue, Feb 24, 2026 at 11:17 AM wangzicheng <wangzicheng@honor.com> wrote:
> > > *snip*
> > > Below is a short summary of what we see.
> > >
> > > Q1: anon/file imbalance and drop in available memory
> > > Android apps workload show a persistent anon/file generational
> > > imbalance under MGLRU:
> > > anon pages tend to stay in the youngest 2 generations;
> > > file pages are spread across multiple generations and over-reclaimed.
> > > Tuning swappiness to 200 and ANON_ONLY does not fully fix this.
> > > On a 16G media workload we see:
> > > MGLRU: MemAvailable ~ 6060 MB
> > > legacy: MemAvailable ~ 6982 MB (differs by ~1G)
> > > Today we mitigate this via explicit memcg aging in Android
> > > userspace [1], which is a vendor-only workaround.
> >
> > One fundamental design of MGLRU is that file generations and anon
> > generations catch up with each other when the generation gap reaches
> > two or more. As a result, even if swappiness is set very high, its
> > effect on aggressively reclaiming anonymous pages is much smaller
> > than with the traditional LRU.
> >
> > One workaround is to force old file folios to be promoted to relatively
> > younger generations, but this could also cause problems by clustering
> > file folios in the newer generations.
> >
> > I wonder if anon and file generations can progress separately to some
> > extent.
> >
>
> To provide some context, the file and anon generations are coupled
> primarily to simplify the MGLRU logic (Original Yu Zhao's intent).
> Separating the two should allow for more flexible policies for sure.
>
> > >
> > > Q4: Lack of global hot/cold + priority view with per-app memcg
> > > Android uses a per-app memcg model and foreground/background levels
> > > for resource control. root reclaim lacks a cross-memcg hot/cold and
> > > priority view;
> > > foreground app file pages may be reclaimed and reloaded frequently,
> > > causing visible stalls;
> > > We currently use a hook [3] to skip reclaim for foreground apps.
> >
> > Interesting. This somehow reflects that the LRU lacks the user’s
> > context, especially on Android systems—for example, which apps are in
> > the foreground, which are in the background, and how long an app has
> > been in the background.
> >
> > But this is not specific to MGLRU; it can also be an issue for the
> > active/inactive LRU?
>
> Pardon my lack of familiarity with the use case, in what ways are
> existing memcg protection features insufficient?

I think he means that whichever memcg is next up on the memcg LRU is
the one that gets reclaimed from first, regardless of whether that
memcg is for a foreground app. Because there is currently no strong
relationship between memcg LRU ordering and Android app state. Android
updates oom_score_adj on app state transitions, so it'd be possible
for the kernel to use that information from userspace to influence
memcg LRU ordering, but I'm not really a great fan of that idea.

Right, reclaim from foreground apps is not exclusively a MGLRU
problem. There is an effort in both MGLRU and active/inactive LRU to
provide some sort of fairness (now both are eventually-fair) for
global reclaim, so that no memcg is the subject of disproportionate
reclaim.

I'm planning to investigate applying memory.low to foreground /
top-app for reducing the amount of reclaim from foreground apps.
However at the same time, we are also working on applying memory
limits to all apps (memory.high) so that no single app (including a
foreground app) can use all the system memory as a matter of Android
policy.

Thanks,
T.J.

> > Additionally, I’d like to add Q5 based on my observations:
> > Q5:
> > MGLRU places readahead folios in the newest generation. For example, if
> > a page fault occurs at address 5, readahead fetches addresses 1–16, and
> > all 16 folios are put in the youngest generation, even though many may
> > not be needed. This can seriously impact reclamation performance, as
> > these cold readahead folios occupy active slots.
> >
> > See the code below and the checks performed by lru_gen_in_fault().
> >
> > void folio_add_lru(struct folio *folio)
> > {
> >         ...
> >         /* see the comment in lru_gen_folio_seq() */
> >         if (lru_gen_enabled() && !folio_test_unevictable(folio) &&
> >             lru_gen_in_fault() && !(current->flags & PF_MEMALLOC))
> >                 folio_set_active(folio);
> >
> >         folio_batch_add_and_move(folio, lru_add);
> > }
> > EXPORT_SYMBOL(folio_add_lru);
> >
> > I could have submitted a patchset to address this by initially marking
> > only address 5 as active, and activating the other addresses later when
> > they are actually mapped or accessed.
>
> I need to read it more closely but that's a good idea.
>
> Thanks,
> Yuanchu
>