[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <8e2417d8-d108-2949-40f2-997d53a3f367@linux.vnet.ibm.com>
Date: Wed, 24 May 2017 18:55:08 -0500
From: Michael Bringmann <mwb@...ux.vnet.ibm.com>
To: Michael Ellerman <mpe@...erman.id.au>,
Reza Arbab <arbab@...ux.vnet.ibm.com>
Cc: 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,
Sebastian Andrzej Siewior <bigeasy@...utronix.de>
Subject: Re: [Patch 2/2]: powerpc/hotplug/mm: Fix hot-add memory node assoc
On 05/24/2017 06:19 AM, Michael Ellerman wrote:
> Michael Bringmann <mwb@...ux.vnet.ibm.com> writes:
>
>> On 05/23/2017 04:49 PM, Reza Arbab wrote:
>>> 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.
>>
>> With or without 3af229f2071f, we would still need to add something, somewhere to add new
>> bits to the 'node_possible_map'. That is not being done.
>
> You mustn't add bits to the possible map after boot.
>
> That's its purpose, to tell you what nodes could ever *possibly* exist.
The problem that I have been encountering is that the 'possible map' did *not*
show all of the possible nodes. Rather, it showed only the nodes that were
assigned memory at boot-up. If more memory were hot-added to the kernel, it
could be assigned into one of the nodes that were skipped at boot. However,
nothing was updating the 'node_possible_map' correctly in the kernel memory
code.
Reza pointed out a code change in commit 3af229f2071f that has not made it into
the 4.12 checkout i.e. removing the instruction that reduces the node_possible_map.
This may well be a suitable replacement for the code that I have here, and I
will test it here next.
>
> cheers
>
>
Later.
--
Michael W. Bringmann
Linux Technology Center
IBM Corporation
Tie-Line 363-5196
External: (512) 286-5196
Cell: (512) 466-0650
mwb@...ux.vnet.ibm.com
Powered by blists - more mailing lists