linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
From: Reza Arbab <arbab@linux.vnet.ibm.com>
To: Balbir Singh <bsingharora@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>,
	Benjamin Herrenschmidt <benh@kernel.crashing.org>,
	Paul Mackerras <paulus@samba.org>,
	Rob Herring <robh+dt@kernel.org>,
	Frank Rowand <frowand.list@gmail.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Bharata B Rao <bharata@linux.vnet.ibm.com>,
	Nathan Fontenot <nfont@linux.vnet.ibm.com>,
	Stewart Smith <stewart@linux.vnet.ibm.com>,
	Alistair Popple <apopple@au1.ibm.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>,
	Tang Chen <tangchen@cn.fujitsu.com>,
	linux-kernel@vger.kernel.org, linuxppc-dev@lists.ozlabs.org,
	devicetree@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH v4 4/5] mm: make processing of movable_node arch-specific
Date: Tue, 25 Oct 2016 19:49:29 -0500	[thread overview]
Message-ID: <20161026004929.h6v54dhehk4yvmwm@arbab-vm> (raw)
In-Reply-To: <112504e9-561d-e0da-7a40-73996c678b56@gmail.com>

On Wed, Oct 26, 2016 at 09:34:18AM +1100, Balbir Singh wrote:
>I still believe we need your changes, I was wondering if we've tested
>it against normal memory nodes and checked if any memblock
>allocations end up there. Michael showed me some memblock
>allocations on node 1 of a two node machine with movable_node

The movable_node option is x86-only. Both of those nodes contain normal 
memory, so allocations on both are allowed.

>> Longer; if you use "movable_node", x86 can identify these nodes at 
>> boot. They call memblock_mark_hotplug() while parsing the SRAT. Then, 
>> when the zones are initialized, those markings are used to determine 
>> ZONE_MOVABLE.
>>
>> We have no analog of this SRAT information, so our movable nodes can 
>> only be created post boot, by hotplugging and explicitly onlining 
>> with online_movable.
>
>Is this true for all of system memory as well or only for nodes
>hotplugged later?

As far as I know, power has nothing like the SRAT that tells us, at 
boot, which memory is hotpluggable. So there is nothing to wire the 
movable_node option up to.

Of course, any memory you hotplug afterwards is, by definition, 
hotpluggable. So we can still create movable nodes that way.

-- 
Reza Arbab

  reply	other threads:[~2016-10-26  0:49 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-06 18:36 [PATCH v4 0/5] powerpc/mm: movable hotplug memory nodes Reza Arbab
2016-10-06 18:36 ` [PATCH v4 1/5] drivers/of: introduce of_fdt_device_is_available() Reza Arbab
2016-10-06 18:36 ` [PATCH v4 2/5] drivers/of: do not add memory for unavailable nodes Reza Arbab
2016-10-11 13:58   ` Rob Herring
2016-10-21  6:22   ` Alistair Popple
2016-10-23  1:51     ` Reza Arbab
2016-10-24 10:24     ` Michael Ellerman
2016-10-24 18:20       ` Reza Arbab
2016-10-06 18:36 ` [PATCH v4 3/5] powerpc/mm: allow memory hotplug into a memoryless node Reza Arbab
2016-10-20  3:30   ` Balbir Singh
2016-10-20 14:38     ` Reza Arbab
2016-10-25  9:39     ` Michael Ellerman
2016-10-06 18:36 ` [PATCH v4 4/5] mm: make processing of movable_node arch-specific Reza Arbab
2016-10-07  6:37   ` Aneesh Kumar K.V
2016-10-11 12:26   ` Balbir Singh
2016-10-25 12:15     ` Balbir Singh
2016-10-25 15:55       ` Reza Arbab
2016-10-25 22:34         ` Balbir Singh
2016-10-26  0:49           ` Reza Arbab [this message]
2016-10-26 10:52             ` Michael Ellerman
2016-10-26 17:03               ` Reza Arbab
2016-10-25 22:59         ` Balbir Singh
2016-10-06 18:36 ` [PATCH v4 5/5] mm: enable CONFIG_MOVABLE_NODE on non-x86 arches Reza Arbab
2016-10-07  6:40   ` Aneesh Kumar K.V
2016-10-11 13:17   ` Balbir Singh

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=20161026004929.h6v54dhehk4yvmwm@arbab-vm \
    --to=arbab@linux.vnet.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=aneesh.kumar@linux.vnet.ibm.com \
    --cc=apopple@au1.ibm.com \
    --cc=benh@kernel.crashing.org \
    --cc=bharata@linux.vnet.ibm.com \
    --cc=bsingharora@gmail.com \
    --cc=devicetree@vger.kernel.org \
    --cc=frowand.list@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=mpe@ellerman.id.au \
    --cc=nfont@linux.vnet.ibm.com \
    --cc=paulus@samba.org \
    --cc=robh+dt@kernel.org \
    --cc=stewart@linux.vnet.ibm.com \
    --cc=tangchen@cn.fujitsu.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).