Re: [PATCH v5 1/9] mm/demotion: Add support for explicit memory tiers

[Aneesh Kumar K V]

On 6/8/22 10:12 PM, Yang Shi wrote:
> On Tue, Jun 7, 2022 at 9:58 PM Aneesh Kumar K V
> <aneesh.kumar@xxxxxxxxxxxxx> wrote:

....

> >    config TIERED_MEMORY
> >          bool "Support for explicit memory tiers"
> > -       def_bool n
> > -       depends on MIGRATION && NUMA
> > -       help
> > -         Support to split nodes into memory tiers explicitly and
> > -         to demote pages on reclaim to lower tiers. This option
> > -         also exposes sysfs interface to read nodes available in
> > -         specific tier and to move specific node among different
> > -         possible tiers.
> > +       def_bool MIGRATION && NUMA
>
> CONFIG_NUMA should be good enough. Memory tiering doesn't have to mean
> demotion/promotion has to be supported IMHO.
>
> >    config HUGETLB_PAGE_SIZE_VARIABLE
> >          def_bool n
> >
> > ie, we just make it a Kconfig variable without exposing it to the user?

We can do that but that would also mean in order to avoid building the 
demotion targets etc we will now have to have multiple #ifdef 
CONFIG_MIGRATION in mm/memory-tiers.c . It builds without those #ifdef 
So these are not really build errors, but rather we will be building all 
the demotion targets for no real use with them.

What usecase do you have to expose memory tiers on a system with 
CONFIG_MIGRATION disabled? CONFIG_MIGRATION gets enabled in almost all 
configs these days due to its dependency against COMPACTION and 
TRANSPARENT_HUGEPAGE.

Unless there is a real need, I am wondering if we can avoid sprinkling 
#ifdef CONFIG_MIGRATION in mm/memory-tiers.c

-aneesh