All of
 help / color / mirror / Atom feed
From: Oscar Salvador <>
To: "Huang, Ying" <>
Cc: Andrew Morton <>,
	Dave Hansen <>,
	Abhishek Goel <>,
	Baolin Wang <>,,
Subject: Re: [PATCH v2] mm: Only re-generate demotion targets when a numa node changes its N_CPU state
Date: Fri, 11 Mar 2022 09:39:52 +0100	[thread overview]
Message-ID: <YisK2PEkKAqtZPfp@localhost.localdomain> (raw)
In-Reply-To: <>

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
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)

Sounds about right?


Oscar Salvador

  reply	other threads:[~2022-03-11  8:39 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-10 12:07 [PATCH v2] mm: Only re-generate demotion targets when a numa node changes its N_CPU state Oscar Salvador
2022-03-11  1:33 ` Baolin Wang
2022-03-11  2:24 ` Huang, Ying
2022-03-11  8:39   ` Oscar Salvador [this message]
2022-03-14  1:03     ` Huang, Ying
2022-03-14 15:13       ` Oscar Salvador
2022-03-14 15:20         ` Dave Hansen
2022-03-15  6:13           ` Oscar Salvador
2022-03-15  6:31             ` Huang, Ying
2022-03-11  2:39 ` Andrew Morton
2022-03-11  9:23   ` Oscar Salvador
2022-03-11 17:10   ` Dave Hansen
2022-03-14  9:09     ` Abhishek Goel
2022-03-11  5:06 ` Huang, Ying
2022-03-11  9:17   ` Oscar Salvador
2022-03-14  3:09     ` Huang, Ying

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=YisK2PEkKAqtZPfp@localhost.localdomain \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.