On Thu, Jun 9, 2022 at 1:18 AM Aneesh Kumar K V <aneesh.kumar@xxxxxxxxxxxxx> wrote: > > 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. Can we have default demotion targets for !MIGRATION? For example, all demotion targets are -1. > > 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. Johannes's interleave series is an example, https://lore.kernel.org/lkml/20220607171949.85796-1-hannes@xxxxxxxxxxx/ It doesn't do any demotion/promotion, just make allocations interleave on different tiers. > > Unless there is a real need, I am wondering if we can avoid sprinkling > #ifdef CONFIG_MIGRATION in mm/memory-tiers.c > > -aneesh
