Re: [PATCH RFC] mm/mglru: lazily activate folios while folios are really mapped

[Barry Song]

On Thu, Mar 19, 2026 at 6:13 PM wangzicheng <wangzicheng@xxxxxxxxx> wrote:
>
> Hi Barry,
>
> Thank you for the suggestion.
>
> I have re-designed the workload and get the relative promising results.
> The workload repeatedly launches and switches between 30 apps
> for 500 rounds. Since the test takes quite a long time, the final results
> appear relatively stable across runs.
>
> The testing was done on an Android 16 device with kernel 6.6.89,
> 8GB RAM, MGLRU enabled.
>
> However, the results are not very easy to interpret.
>
> Average number of kept-alive apps: ±0.08 apps
> Average available memory (sampled after each app launch):
> baseline vs patched: 2216MB vs 2218MB (~2MB difference)
>
> Below is the vmstat comparison (patched vs baseline):
>
> Metric                       Change
> ---------------------------  --------
> pgpgin                       +2.06%
> pgpgout                      +3.10%
> pswpin                       +14.13%
> pswpout                      +4.55%
> pgfault                      -3.19%
> pgmajfault                   +12.75%
> workingset_refault_anon      +14.77%
> workingset_refault_file      +3.48%
> workingset_activate_anon     -3.45%
> workingset_activate_file     -17.76%
> workingset_restore_anon      -3.44%
> workingset_restore_file      -19.13%
>
> In v6.6, when PG_active is set, pages go to the youngest generation,
> while pages without PG_active go to the second oldest generation.
> ```
> static inline bool lru_gen_add_folio(
> ...
>               if (folio_test_active(folio))
>                 seq = lrugen->max_seq;
>         ...
>         else
>                 seq = lrugen->min_seq[type] + 1;
> ```
>
> My rough expectation was that the patch should make file pages more
> prone to reclaim and make file page hot/cold aging more accurate, so
> both file refault and anon refault might decrease. But here anon refault
> increases instead.
>
> I’m not sure if this assumption is correct. Could you share your thoughts
> on how to interpret these results?

Probably because readahead folios are soon mapped via
fault-around. Currently, the fault_around_pages value is quite
large.

There is an Android hook available for adjusting fault-around:

static inline bool should_fault_around(struct vm_fault *vmf)
{
        bool should_around = true;
        /* No ->map_pages?  No way to fault around... */
        if (!vmf->vma->vm_ops->map_pages)
                return false;

        if (uffd_disable_fault_around(vmf->vma))
                return false;

        trace_android_vh_should_fault_around(vmf, &should_around);
        if (!should_around)
                return false;

        /* A single page implies no faulting 'around' at all. */
        return fault_around_pages > 1;
}

If you reduce fault-around from 16 pages to 4 pages when
available memory falls below a certain threshold, you’ll see
this RFC deliver a significant improvement on low-memory
devices, such as 8 GB phones.

But for mainline, we still need an approach that can be merged.

Traditional LRU relies on PTE scanning to activate folios,
while MGLRU assumes mapped folios should be activated.
However, fault-around may map folios that are not actually
needed. If we drop activation in map_pages, we miss future
opportunities to promote those folios at mapping time.

Best Regards
Barry