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

[wangzicheng <wangzicheng@honor.com>]

> > >
> > > 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.
Hi T.J.,

Yes, exactly.

> 
> 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.
That sounds good to me. We're also experimenting with a similar approach.

In my opinion, these knobs are a good opportunity to combine some ML
and autotuning (in userspace, not in kernel space as the kernel-ML
patches did):
- explore a reasonable memory.low / memory.high range for a given app,
  to both save memory and still keep good UX (hot launch / animations);
- classify apps into a few categories, and then reuse the tuned limits
  for apps in the same class.

Best,
Zicheng

> 
> > > 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
> >