On Fri, Mar 11, 2022 at 10:24:07AM +0800, Huang, Ying wrote: > It may be unnecessary to be fixed in this patch. But I think we need to > cleanup the kernel config dependencies of the demotion code at some time. I am glad you brought this up because it is something I have been thinking about. I already added it in my to-do list, but I would do it in a separate patch if you do not mind. Now, let us try to untangle this mess: > 1. Even if !defined(CONFIG_HOTPLUG_CPU) && > !defined(CONFIG_MEMORY_HOTPLUG), we still need to allocate > "node_demotion" and call set_migration_target_nodes() during boot time. > > 2. If !defined(CONFIG_MEMORY_HOTPLUG), we don't need > migrate_on_reclaim_callback(). > > 3. We need defined(CONFIG_NUMA) && defined(CONFIG_MIGRATION) for all > these code. Back in the early versions [1] I asked whether we could have some scenario where this feature could be used when !CONFIG_MEMORY_HOTPLUG [2]. The reason I was given is that in order to bind the expose PMEM memory as RAM (add_memory_driver_managed()), we need MEMORY_HOTPLUG. Now, as I said back then, I am not sure whether PMEM memory can be exposed as RAM by other means, but as it was pointed out back then, it really looks like we, at least, need CONFIG_MEMORY_HOTPLUG. Ok, so we have our first dependency: CONFIG_MEMORY_HOTPLUG. Now, about CONFIG_HOTPLUG_CPU, it seems that that is not a strong dependency, as we do not need cpu-hotplug in order to use the feature. We definitely need CONFIG_MIGRATION and CONFIG_NUMA though. So, we have something like: - Depends: * CONFIG_NUMA (obvius) * CONFIG_MIGRATION (to migrate between nodes) * CONFIG_MEMORY_HOTPLUG (to expose PMEM as RAM) Sounds about right? [1] https://patchwork.kernel.org/project/linux-mm/patch/20210401183221.977831DE@xxxxxxxxxxxxxxxxxx/#24099405 [2] https://patchwork.kernel.org/project/linux-mm/patch/20210401183221.977831DE@xxxxxxxxxxxxxxxxxx/#24103467 -- Oscar Salvador SUSE Labs
