[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <87h999wbxi.fsf@linux.vnet.ibm.com>
Date: Wed, 21 Sep 2016 20:13:37 +0530
From: "Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To: Reza Arbab <arbab@...ux.vnet.ibm.com>
Cc: Michael Ellerman <mpe@...erman.id.au>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Paul Mackerras <paulus@...ba.org>,
Rob Herring <robh+dt@...nel.org>,
Frank Rowand <frowand.list@...il.com>,
Jonathan Corbet <corbet@....net>,
Andrew Morton <akpm@...ux-foundation.org>,
Bharata B Rao <bharata@...ux.vnet.ibm.com>,
Nathan Fontenot <nfont@...ux.vnet.ibm.com>,
Stewart Smith <stewart@...ux.vnet.ibm.com>,
Alistair Popple <apopple@....ibm.com>,
Balbir Singh <bsingharora@...il.com>,
linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
linuxppc-dev@...ts.ozlabs.org, devicetree@...r.kernel.org,
linux-mm@...ck.org
Subject: Re: [PATCH v2 3/3] mm: enable CONFIG_MOVABLE_NODE on powerpc
Reza Arbab <arbab@...ux.vnet.ibm.com> writes:
> On Wed, Sep 21, 2016 at 12:39:51PM +0530, Aneesh Kumar K.V wrote:
>>What I was checking was how will one mark a node movable in ppc64 ? I
>>don't see ppc64 code doing the equivalent of memblock_mark_hotplug().
>
> Post boot, the marking mechanism is not necessary. You can create a
> movable node by putting all of the node's memory into ZONE_MOVABLE
> during the hotplug.
>
>>So when you say "Onlining memory into ZONE_MOVABLE requires
>>CONFIG_MOVABLE_NODE" where is that restriction ?. IIUC,
>>should_add_memory_movable() will only return ZONE_MOVABLE only if it is
>>non empty and MOVABLE_NODE will create a ZONE_MOVABLE zone by default
>>only if it finds a memblock marked hotpluggable. So wondering if we
>>are not calling memblock_mark_hotplug() how is it working. Or am I
>>missing something ?
>
> You are looking at the addition step of hotplug. You're correct there,
> the memory is added to the default zone, not ZONE_MOVABLE. The
> transition to ZONE_MOVABLE takes place during the onlining step. In
> online_pages():
>
> zone = move_pfn_range(zone_shift, pfn, pfn + nr_pages);
>
> The reason we need CONFIG_MOVABLE_NODE is right before that:
>
> if ((zone_idx(zone) > ZONE_NORMAL ||
> online_type == MMOP_ONLINE_MOVABLE) &&
> !can_online_high_movable(zone))
> return -EINVAL;
>
So we are looking at two step online process here. The above explained
the details nicely. Can you capture these details in the commit message. ie,
to say that when using 'echo online-movable > state' we allow the move from
normal to movable only if movable node is set. Also you may want to
mention that we still don't support the auto-online to movable.
> where can_online_high_movable() is defined like this:
>
> #ifdef CONFIG_MOVABLE_NODE
> /*
> * When CONFIG_MOVABLE_NODE, we permit onlining of a node which doesn't have
> * normal memory.
> */
> static bool can_online_high_movable(struct zone *zone)
> {
> return true;
> }
> #else /* CONFIG_MOVABLE_NODE */
> /* ensure every online node has NORMAL memory */
> static bool can_online_high_movable(struct zone *zone)
> {
> return node_state(zone_to_nid(zone), N_NORMAL_MEMORY);
> }
> #endif /* CONFIG_MOVABLE_NODE */
>
> To be more clear, I can change the commit log to say "Onlining all of a
> node's memory into ZONE_MOVABLE requires CONFIG_MOVABLE_NODE".
>
> --
> Reza Arbab
-aneesh
Powered by blists - more mailing lists