From: Wei Yang <richard.weiyang@gmail.com>
To: Michal Hocko <mhocko@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, Mel Gorman <mgorman@suse.de>,
Vlastimil Babka <vbabka@suse.cz>,
Andrea Arcangeli <aarcange@redhat.com>,
Reza Arbab <arbab@linux.vnet.ibm.com>,
Yasuaki Ishimatsu <yasu.isimatu@gmail.com>,
qiuxishi@huawei.com, Kani Toshimitsu <toshi.kani@hpe.com>,
slaoub@gmail.com, Joonsoo Kim <js1304@gmail.com>,
Andi Kleen <ak@linux.intel.com>,
David Rientjes <rientjes@google.com>,
Daniel Kiper <daniel.kiper@oracle.com>,
Igor Mammedov <imammedo@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
LKML <linux-kernel@vger.kernel.org>,
Michal Hocko <mhocko@suse.com>
Subject: Re: [PATCH] mm, memory_hotplug: support movable_node for hotplugable nodes
Date: Mon, 12 Jun 2017 12:28:32 +0800 [thread overview]
Message-ID: <20170612042832.GA7429@WeideMBP.lan> (raw)
In-Reply-To: <20170608122318.31598-1-mhocko@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 3384 bytes --]
On Thu, Jun 08, 2017 at 02:23:18PM +0200, Michal Hocko wrote:
>From: Michal Hocko <mhocko@suse.com>
>
>movable_node kernel parameter allows to make hotplugable NUMA
>nodes to put all the hotplugable memory into movable zone which
>allows more or less reliable memory hotremove. At least this
>is the case for the NUMA nodes present during the boot (see
>find_zone_movable_pfns_for_nodes).
>
When movable_node is enabled, we would have overlapped zones, right?
To be specific, only ZONE_MOVABLE could have memory ranges belongs to other
zones.
This looks a little different in the whole ZONE design.
>This is not the case for the memory hotplug, though.
>
> echo online > /sys/devices/system/memory/memoryXYZ/status
>
>will default to a kernel zone (usually ZONE_NORMAL) unless the
>particular memblock is already in the movable zone range which is not
^^^
Here is memblock or a memory_block?
>the case normally when onlining the memory from the udev rule context
>for a freshly hotadded NUMA node. The only option currently is to have a
So the semantic you want to change here is to make the memory_block in
ZONE_MOVABLE when movable_node is enabled.
Besides this, movable_node is enabled, what other requirements? Like, this
memory_block should next to current ZONE_MOVABLE ? or something else?
>special udev rule to echo online_movable to all memblocks belonging to
>such a node which is rather clumsy. Not the mention this is inconsistent
^^^
Hmm... "Not to mentions" looks more understandable.
BTW, I am not a native speaker. If this usage is correct, just ignore this
comment.
>as well because what ended up in the movable zone during the boot will
>end up in a kernel zone after hotremove & hotadd without special care.
>
>It would be nice to reuse memblock_is_hotpluggable but the runtime
>hotplug doesn't have that information available because the boot and
>hotplug paths are not shared and it would be really non trivial to
>make them use the same code path because the runtime hotplug doesn't
>play with the memblock allocator at all.
>
>Teach move_pfn_range that MMOP_ONLINE_KEEP can use the movable zone if
>movable_node is enabled and the range doesn't overlap with the existing
>normal zone. This should provide a reasonable default onlining strategy.
>
>Strictly speaking the semantic is not identical with the boot time
>initialization because find_zone_movable_pfns_for_nodes covers only the
>hotplugable range as described by the BIOS/FW. From my experience this
>is usually a full node though (except for Node0 which is special and
>never goes away completely). If this turns out to be a problem in the
>real life we can tweak the code to store hotplug flag into memblocks
>but let's keep this simple now.
>
Let me try to understand your purpose of this change.
If a memblock has MEMBLOCK_HOTPLU set, it would be in ZONE_MOVABLE during
bootup. While a hotplugged memory_block would be in ZONE_NORMAL without
special care.
So you want to make sure when movable_node is enabled, the hotplugged
memory_block would be in ZONE_MOVABLE. Is this correct?
One more thing is do we have MEMBLOCK_HOTPLU for a hotplugged memory_block?
>Signed-off-by: Michal Hocko <mhocko@suse.com>
>---
>
--
Wei Yang
Help you, Help me
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
next prev parent reply other threads:[~2017-06-12 4:28 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-08 12:23 [PATCH] mm, memory_hotplug: support movable_node for hotplugable nodes Michal Hocko
2017-06-08 12:23 ` Michal Hocko
2017-06-10 14:33 ` Wei Yang
2017-06-12 6:35 ` Michal Hocko
2017-06-12 6:35 ` Michal Hocko
2017-06-11 1:45 ` Wei Yang
2017-06-12 6:37 ` Michal Hocko
2017-06-12 6:37 ` Michal Hocko
2017-06-12 4:28 ` Wei Yang [this message]
2017-06-12 6:45 ` Michal Hocko
2017-06-12 6:45 ` Michal Hocko
2017-06-14 9:06 ` Wei Yang
2017-06-14 9:07 ` Vlastimil Babka
2017-06-14 9:07 ` Vlastimil Babka
2017-06-15 1:03 ` Wei Yang
2017-06-15 3:13 ` Wei Yang
2017-06-15 8:16 ` Michal Hocko
2017-06-15 8:16 ` Michal Hocko
2017-06-12 8:58 ` Vlastimil Babka
2017-06-12 8:58 ` Vlastimil Babka
2017-06-12 11:12 ` [PATCH -v2] " Michal Hocko
2017-06-12 11:12 ` Michal Hocko
2017-06-15 3:29 ` [PATCH] " Wei Yang
2017-06-15 8:24 ` Michal Hocko
2017-06-15 8:24 ` Michal Hocko
2017-06-15 15:43 ` Reza Arbab
2017-06-15 15:43 ` Reza Arbab
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=20170612042832.GA7429@WeideMBP.lan \
--to=richard.weiyang@gmail.com \
--cc=aarcange@redhat.com \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=arbab@linux.vnet.ibm.com \
--cc=daniel.kiper@oracle.com \
--cc=imammedo@redhat.com \
--cc=js1304@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--cc=mhocko@suse.com \
--cc=qiuxishi@huawei.com \
--cc=rientjes@google.com \
--cc=slaoub@gmail.com \
--cc=toshi.kani@hpe.com \
--cc=vbabka@suse.cz \
--cc=vkuznets@redhat.com \
--cc=yasu.isimatu@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.