[PATCH v7 05/12] mm: multigenerational LRU: minimal implementation

[Yu Zhao]

On Wed, Feb 23, 2022 at 1:28 AM Huang, Ying <ying.huang at intel.com> wrote:
>
> Hi, Yu,
>
> Yu Zhao <yuzhao at google.com> writes:
>
> > To avoid confusions, the terms "promotion" and "demotion" will be
> > applied to the multigenerational LRU, as a new convention; the terms
> > "activation" and "deactivation" will be applied to the active/inactive
> > LRU, as usual.
>
> In the memory tiering related commits and patchset, for example as follows,
>
> commit 668e4147d8850df32ca41e28f52c146025ca45c6
> Author: Yang Shi <yang.shi at linux.alibaba.com>
> Date:   Thu Sep 2 14:59:19 2021 -0700
>
>     mm/vmscan: add page demotion counter
>
> https://lore.kernel.org/linux-mm/20220221084529.1052339-1-ying.huang@intel.com/
>
> "demote" and "promote" is used for migrating pages between different
> types of memory.  Is it better for us to avoid overloading these words
> too much to avoid the possible confusion?

Given that LRU and migration are usually different contexts, I think
we'd be fine, unless we want a third pair of terms.

> > +static int get_swappiness(struct mem_cgroup *memcg)
> > +{
> > +     return mem_cgroup_get_nr_swap_pages(memcg) >= MIN_LRU_BATCH ?
> > +            mem_cgroup_swappiness(memcg) : 0;
> > +}
>
> After we introduced demotion support in Linux kernel.  The anonymous
> pages in the fast memory node could be demoted to the slow memory node
> via the page reclaiming mechanism as in the following commit.  Can you
> consider that too?

Sure. How do I check whether there is still space on the slow node?