From: David Hildenbrand <david@redhat.com>
To: Dave Hansen <dave.hansen@intel.com>,
"Huang, Ying" <ying.huang@intel.com>,
Dave Hansen <dave.hansen@linux.intel.com>
Cc: linux-kernel@vger.kernel.org, oliver.sang@intel.com,
mhocko@suse.com, weixugc@google.com, osalvador@suse.de,
rientjes@google.com, dan.j.williams@intel.com,
gthelen@google.com, yang.shi@linux.alibaba.com,
akpm@linux-foundation.org
Subject: Re: [PATCH 1/2] mm/migrate: optimize hotplug-time demotion order updates
Date: Tue, 21 Sep 2021 09:23:18 +0200 [thread overview]
Message-ID: <4e3d98eb-e8b9-90a8-638c-e19a5367df99@redhat.com> (raw)
In-Reply-To: <2d7e4078-f9c0-7511-0bab-de5dab25b45d@intel.com>
On 20.09.21 23:37, Dave Hansen wrote:
> On 9/17/21 5:55 PM, Huang, Ying wrote:
>>> @@ -3147,6 +3177,16 @@ static void __set_migration_target_nodes
>>> int node;
>>>
>>> /*
>>> + * The "migration path" array is heavily optimized
>>> + * for reads. This is the write side which incurs a
>>> + * very heavy synchronize_rcu(). Avoid this overhead
>>> + * when nothing of consequence has changed since the
>>> + * last write.
>>> + */
>>> + if (!node_demotion_topo_changed())
>>> + return;
>>> +
>>> + /*
>>> * Avoid any oddities like cycles that could occur
>>> * from changes in the topology. This will leave
>>> * a momentary gap when migration is disabled.
>> Now synchronize_rcu() is called in disable_all_migrate_targets(), which
>> is called for MEM_GOING_OFFLINE. Can we remove the synchronize_rcu()
>> from disable_all_migrate_targets() and call it in
>> __set_migration_target_nodes() before we update the node_demotion[]?
>
> I see what you are saying. This patch just targeted
> __set_migration_target_nodes() which is called in for
> MEM_ONLINE/OFFLINE. But, it missed MEM_GOING_OFFLINE's call to
> disable_all_migrate_targets().
>
> I think I found something better than what I had in this patch, or the
> tweak you suggested: The 'memory_notify->status_change_nid' field is
> passed to all memory hotplug notifiers and tells us whether the node is
> going online/offline. Instead of trying to track the changes, I think
> we can simply rely on it to tell us when a node is going online/offline.
>
> This removes the need for the demotion code to track *any* state. I've
> attached a totally untested patch to do this.
>
Sounds sane to me (although I really detest that status_change_nid...
interface).
I was just about to ask "but how does this interact with !CONFIG_NUMA"
... until I realized that having a single node go completely offline is
rather unrealistic ;)
--
Thanks,
David / dhildenb
next prev parent reply other threads:[~2021-09-21 7:23 UTC|newest]
Thread overview: 14+ 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 [this message]
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
-- strict thread matches above, loose matches on Subject: below --
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 1/2] mm/migrate: optimize hotplug-time demotion order updates Dave Hansen
2021-09-24 16:12 ` Dave Hansen
2021-09-24 16:45 ` David Hildenbrand
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=4e3d98eb-e8b9-90a8-638c-e19a5367df99@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=gthelen@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mhocko@suse.com \
--cc=oliver.sang@intel.com \
--cc=osalvador@suse.de \
--cc=rientjes@google.com \
--cc=weixugc@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.