Re: [Chapter One] THP zones: the use cases of policy zones

[Yu Zhao <yuzhao@google.com>]

On Tue, Mar 5, 2024 at 4:04 PM Barry Song <21cnbao@gmail.com> wrote:
>
> On Tue, Mar 5, 2024 at 11:07 PM Vlastimil Babka <vbabka@suse.cz> wrote:
> >
> > On 3/5/24 09:41, Barry Song wrote:
> > > We did implement similar idea in the pageblock granularity on OPPO's
> > > phones by extending two special migratetypes[1]:
> > >
> > > * QUAD_TO_TRIP - this is mainly for 4-order mTHP allocation which can use
> > > ARM64's CONT-PTE; but can rarely be splitted into 3 order to dull the pain
> > > of 3-order allocation if and only if 3-order allocation has failed in both
> > > normal buddy and the below TRIP_TO_QUAD.
> > >
> > > * TRIP_TO_QUAD - this is mainly for 4-order mTHP allocation which can use
> > > ARM64's CONT-PTE; but can sometimes be splitted into 3 order to dull the
> > > pain of 3-order allocation if and only if 3-order allocation has failed in
> > > normal buddy.
> > >
> > > neither of above will be merged into 5 order or above; neither of above
> > > will be splitted into 2 order or lower.
> > >
> > > in compaction, we will skip both of above. I am seeing one disadvantage
> > > of this approach is that I have to add a separate LRU list in each
> > > zone to place those mTHP folios. if mTHP and small folios are put
> > > in the same LRU list, the reclamation efficiency is extremely bad.
> > >
> > > A separate zone, on the other hand, can avoid a separate LRU list
> > > for mTHP as the new zone has its own LRU list.
> >
> > But we switched from per-zone to per-node LRU lists years ago?
> > Is that actually a complication for the policy zones? Or does this work
> > silently assume multigen lru which (IIRC) works differently?
>
> the latter. based on the below code, i believe mglru is different
> with active/inactive,
>
> void lru_gen_init_lruvec(struct lruvec *lruvec)
> {
>         int i;
>         int gen, type, zone;
>         struct lru_gen_folio *lrugen = &lruvec->lrugen;
>
>         lrugen->max_seq = MIN_NR_GENS + 1;
>         lrugen->enabled = lru_gen_enabled();
>
>         for (i = 0; i <= MIN_NR_GENS + 1; i++)
>                 lrugen->timestamps[i] = jiffies;
>
>         for_each_gen_type_zone(gen, type, zone)
>                 INIT_LIST_HEAD(&lrugen->folios[gen][type][zone]);
>
>         lruvec->mm_state.seq = MIN_NR_GENS;
> }
>
> A fundamental difference is that mglru has a different aging and
> eviction mechanism,
> This can synchronize the LRUs of each zone to move forward at the same
> pace while
> the active/inactive might be unable to compare the ages of folios across zones.

That's correct. The active/inactive should also work with the extra
zones, just like it does for ZONE_MOVABLE. But it's not as optimized
as MGLRU, e.g., targeting eligible zones without search the entire LRU
list containing folios from all zones.