All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wei Xu <weixugc@google.com>
To: Dave Hansen <dave.hansen@linux.intel.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Huang Ying <ying.huang@intel.com>, Michal Hocko <mhocko@suse.com>,
	Oscar Salvador <osalvador@suse.de>,
	David Rientjes <rientjes@google.com>,
	Dan Williams <dan.j.williams@intel.com>,
	David Hildenbrand <david@redhat.com>,
	Greg Thelen <gthelen@google.com>,
	Yang Shi <yang.shi@linux.alibaba.com>,
	akpm@linux-foundation.org
Subject: Re: [PATCH 2/2] mm/migrate: add CPU hotplug to demotion #ifdef
Date: Fri, 17 Sep 2021 16:04:56 -0700	[thread overview]
Message-ID: <CAAPL-u_Tig1jK=mv_r=j-A-hR3Kpu7txiSFbPR3a8O1qhM1s-Q@mail.gmail.com> (raw)
In-Reply-To: <20210917223507.913387AB@davehans-spike.ostc.intel.com>

The initialization of node_demotion doesn't have to depend on
CONFIG_MEMORY_HOTPLUG and CONFIG_HOTPLUG_CPU.  While you are at this,
can you replace cpuhp_setup_state() with cpuhp_setup_state_nocalls()
and also call set_migration_target_nodes() directly in
migrate_on_reclaim_init() outside
CONFIG_MEMORY_HOTPLUG/CONFIG_HOTPLUG_CPU?  Thanks.

Wei

On Fri, Sep 17, 2021 at 3:35 PM Dave Hansen <dave.hansen@linux.intel.com> wrote:
>
>
> From: Dave Hansen <dave.hansen@linux.intel.com>
>
> Once upon a time, the node demotion updates were driven solely by
> memory hotplug events.  But now, there are  handlers for both CPU
> and memory hotplug.
>
> However, the #ifdef around the code checks only memory hotplug.
> A system that has HOTPLUG_CPU=y but MEMORY_HOTPLUG=n would miss
> CPU hotplug events.
>
> Update the #ifdef around the common code.  Add memory and
> CPU-specific #ifdefs for their handlers.  These memory/CPU
> #ifdefs avoid unused function warnings when their Kconfig option
> is off.
>
> Fixes: 884a6e5d1f93 ("mm/migrate: update node demotion order on hotplug events")
> Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
> Cc: "Huang, Ying" <ying.huang@intel.com>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Wei Xu <weixugc@google.com>
> Cc: Oscar Salvador <osalvador@suse.de>
> Cc: David Rientjes <rientjes@google.com>
> Cc: Dan Williams <dan.j.williams@intel.com>
> Cc: David Hildenbrand <david@redhat.com>
> Cc: Greg Thelen <gthelen@google.com>
> Cc: Yang Shi <yang.shi@linux.alibaba.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> ---
>
>  b/mm/migrate.c |   46 +++++++++++++++++++++++++---------------------
>  1 file changed, 25 insertions(+), 21 deletions(-)
>
> diff -puN mm/migrate.c~add-cpu-hotplug-config mm/migrate.c
> --- a/mm/migrate.c~add-cpu-hotplug-config       2021-09-16 16:14:01.770140593 -0700
> +++ b/mm/migrate.c      2021-09-17 11:30:19.197027668 -0700
> @@ -3066,7 +3066,7 @@ void migrate_vma_finalize(struct migrate
>  EXPORT_SYMBOL(migrate_vma_finalize);
>  #endif /* CONFIG_DEVICE_PRIVATE */
>
> -#if defined(CONFIG_MEMORY_HOTPLUG)
> +#if defined(CONFIG_MEMORY_HOTPLUG) || defined(CONFIG_HOTPLUG_CPU)
>  /* Disable reclaim-based migration. */
>  static void __disable_all_migrate_targets(void)
>  {
> @@ -3248,25 +3248,7 @@ static void set_migration_target_nodes(v
>         put_online_mems();
>  }
>
> -/*
> - * React to hotplug events that might affect the migration targets
> - * like events that online or offline NUMA nodes.
> - *
> - * The ordering is also currently dependent on which nodes have
> - * CPUs.  That means we need CPU on/offline notification too.
> - */
> -static int migration_online_cpu(unsigned int cpu)
> -{
> -       set_migration_target_nodes();
> -       return 0;
> -}
> -
> -static int migration_offline_cpu(unsigned int cpu)
> -{
> -       set_migration_target_nodes();
> -       return 0;
> -}
> -
> +#if defined(CONFIG_MEMORY_HOTPLUG)
>  /*
>   * This leaves migrate-on-reclaim transiently disabled between
>   * the MEM_GOING_OFFLINE and MEM_OFFLINE events.  This runs
> @@ -3313,6 +3295,27 @@ static int __meminit migrate_on_reclaim_
>
>         return notifier_from_errno(0);
>  }
> +#endif /* CONFIG_MEMORY_HOTPLUG */
> +
> +#ifdef CONFIG_HOTPLUG_CPU
> +/*
> + * React to hotplug events that might affect the migration targets
> + * like events that online or offline NUMA nodes.
> + *
> + * The ordering is also currently dependent on which nodes have
> + * CPUs.  That means we need CPU on/offline notification too.
> + */
> +static int migration_online_cpu(unsigned int cpu)
> +{
> +       set_migration_target_nodes();
> +       return 0;
> +}
> +
> +static int migration_offline_cpu(unsigned int cpu)
> +{
> +       set_migration_target_nodes();
> +       return 0;
> +}
>
>  static int __init migrate_on_reclaim_init(void)
>  {
> @@ -3333,4 +3336,5 @@ static int __init migrate_on_reclaim_ini
>         return 0;
>  }
>  late_initcall(migrate_on_reclaim_init);
> -#endif /* CONFIG_MEMORY_HOTPLUG */
> +#endif /* CONFIG_HOTPLUG_CPU */
> +#endif /* CONFIG_MEMORY_HOTPLUG || CONFIG_HOTPLUG_CPU */
> _

  reply	other threads:[~2021-09-17 23:05 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-17 22:35 [PATCH 0/2] mm/migrate: 5.15 fixes for automatic demotion Dave Hansen
2021-09-17 22:35 ` [PATCH 1/2] mm/migrate: optimize hotplug-time demotion order updates Dave Hansen
2021-09-18  0:55   ` Huang, Ying
2021-09-20 21:37     ` Dave Hansen
2021-09-21  7:23       ` David Hildenbrand
2021-09-21 14:36       ` Huang, Ying
2021-09-21 17:01         ` Dave Hansen
2021-09-22  2:19           ` Huang, Ying
2021-09-23  4:44         ` Huang, Ying
2021-09-17 22:35 ` [PATCH 2/2] mm/migrate: add CPU hotplug to demotion #ifdef Dave Hansen
2021-09-17 23:04   ` Wei Xu [this message]
2021-09-24 16:12 [PATCH 0/2] [v2] mm/migrate: 5.15 fixes for automatic demotion Dave Hansen
2021-09-24 16:12 ` [PATCH 2/2] mm/migrate: add CPU hotplug to demotion #ifdef Dave Hansen
2021-09-24 16:12   ` Dave Hansen

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to='CAAPL-u_Tig1jK=mv_r=j-A-hR3Kpu7txiSFbPR3a8O1qhM1s-Q@mail.gmail.com' \
    --to=weixugc@google.com \
    --cc=akpm@linux-foundation.org \
    --cc=dan.j.williams@intel.com \
    --cc=dave.hansen@linux.intel.com \
    --cc=david@redhat.com \
    --cc=gthelen@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mhocko@suse.com \
    --cc=osalvador@suse.de \
    --cc=rientjes@google.com \
    --cc=yang.shi@linux.alibaba.com \
    --cc=ying.huang@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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.