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 && NUMACONFIG_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
