[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170523214922.bns675oqzqj4pkhc@arbab-laptop.localdomain>
Date: Tue, 23 May 2017 16:49:22 -0500
From: Reza Arbab <arbab@...ux.vnet.ibm.com>
To: Michael Bringmann <mwb@...ux.vnet.ibm.com>
Cc: Balbir Singh <bsingharora@...il.com>,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>,
linux-kernel@...r.kernel.org, Paul Mackerras <paulus@...ba.org>,
"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
Bharata B Rao <bharata@...ux.vnet.ib>,
Shailendra Singh <shailendras@...dia.com>,
Thomas Gleixner <tglx@...utronix.de>,
linuxppc-dev@...ts.ozlabs.org
Subject: Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc
On Tue, May 23, 2017 at 03:05:08PM -0500, Michael Bringmann wrote:
>On 05/23/2017 10:52 AM, Reza Arbab wrote:
>> On Tue, May 23, 2017 at 10:15:44AM -0500, Michael Bringmann wrote:
>>> +static void setup_nodes(void)
>>> +{
>>> + int i, l = 32 /* MAX_NUMNODES */;
>>> +
>>> + for (i = 0; i < l; i++) {
>>> + if (!node_possible(i)) {
>>> + setup_node_data(i, 0, 0);
>>> + node_set(i, node_possible_map);
>>> + }
>>> + }
>>> +}
>>
>> This seems to be a workaround for 3af229f2071f ("powerpc/numa: Reset node_possible_map to only node_online_map").
>
>They may be related, but that commit is not a replacement. The above patch ensures that
>there are enough of the nodes initialized at startup to allow for memory hot-add into a
>node that was not used at boot. (See 'setup_node_data' function in 'numa.c'.) That and
>recording that the node was initialized.
Is it really necessary to preinitialize these empty nodes using
setup_node_data()? When you do memory hotadd into a node that was not
used at boot, the node data already gets set up by
add_memory
add_memory_resource
hotadd_new_pgdat
arch_alloc_nodedata <-- allocs the pg_data_t
...
free_area_init_node <-- sets NODE_DATA(nid)->node_id, etc.
Removing setup_node_data() from that loop leaves only the call to
node_set(). If 3af229f2071f (which reduces node_possible_map) was
reverted, you wouldn't need to do that either.
>I didn't see where any part of commit 3af229f2071f would touch the 'node_possible_map'
>which is needed by 'numa.c' and 'workqueue.c'. The nodemask created and updated by
>'mem_cgroup_may_update_nodemask()' does not appear to be the same mask.
Are you sure you're looking at 3af229f2071f? It only adds one line of
code; the reduction of node_possible_map.
--
Reza Arbab
Powered by blists - more mailing lists