[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aafc39d0-a002-f851-7da8-cf768ebe691d@intel.com>
Date: Tue, 9 Mar 2021 14:07:44 -0800
From: Dave Hansen <dave.hansen@...el.com>
To: Yang Shi <shy828301@...il.com>,
Dave Hansen <dave.hansen@...ux.intel.com>
Cc: Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Linux MM <linux-mm@...ck.org>,
Yang Shi <yang.shi@...ux.alibaba.com>,
David Rientjes <rientjes@...gle.com>,
Huang Ying <ying.huang@...el.com>,
Dan Williams <dan.j.williams@...el.com>,
David Hildenbrand <david@...hat.com>,
Oscar Salvador <osalvador@...e.de>
Subject: Re: [PATCH 03/10] mm/migrate: update node demotion order during on
hotplug events
On 3/8/21 4:03 PM, Yang Shi wrote:
>> +static int __meminit migrate_on_reclaim_callback(struct notifier_block *self,
>> + unsigned long action, void *arg)
>> +{
>> + switch (action) {
>> + case MEM_GOING_OFFLINE:
>> + /*
>> + * Make sure there are not transient states where
>> + * an offline node is a migration target. This
>> + * will leave migration disabled until the offline
>> + * completes and the MEM_OFFLINE case below runs.
>> + */
>> + disable_all_migrate_targets();
>> +
>> + /*
>> + * Ensure the disable operation is globally visible.
>> + * This avoids readers ever being able to
>> + * simultaneously observe the old (pre-hotplug) and
>> + * new (post-hotplug) migration targets.
>> + */
>> + synchronize_rcu();
> It seems disable_all_migrate_targets() already has synchronize_rcu()
> called. We don't need to call it twice. Otherwise, it looks good to
> me. Reviewed-by: Yang Shi <shy828301@...il.com>
Thanks for noticing that. I've fixed it up.
Powered by blists - more mailing lists