[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170405205529.2bs4yhrfffmkwi5g@arbab-laptop>
Date: Wed, 5 Apr 2017 15:55:29 -0500
From: Reza Arbab <arbab@...ux.vnet.ibm.com>
To: Michal Hocko <mhocko@...nel.org>
Cc: Mel Gorman <mgorman@...e.de>, linux-mm@...ck.org,
Andrew Morton <akpm@...ux-foundation.org>,
Vlastimil Babka <vbabka@...e.cz>,
Andrea Arcangeli <aarcange@...hat.com>,
Yasuaki Ishimatsu <yasu.isimatu@...il.com>,
Tang Chen <tangchen@...fujitsu.com>, qiuxishi@...wei.com,
Kani Toshimitsu <toshi.kani@....com>, slaoub@...il.com,
Joonsoo Kim <js1304@...il.com>,
Andi Kleen <ak@...ux.intel.com>,
Zhang Zhen <zhenzhang.zhang@...wei.com>,
David Rientjes <rientjes@...gle.com>,
Daniel Kiper <daniel.kiper@...cle.com>,
Igor Mammedov <imammedo@...hat.com>,
Vitaly Kuznetsov <vkuznets@...hat.com>,
LKML <linux-kernel@...r.kernel.org>,
Chris Metcalf <cmetcalf@...lanox.com>,
Dan Williams <dan.j.williams@...il.com>,
Heiko Carstens <heiko.carstens@...ibm.com>,
Lai Jiangshan <laijs@...fujitsu.com>,
Martin Schwidefsky <schwidefsky@...ibm.com>
Subject: Re: [PATCH 0/6] mm: make movable onlining suck less
On Wed, Apr 05, 2017 at 06:34:39PM +0200, Michal Hocko wrote:
>This is really interesting. Because add_memory_resource does the
>following
> /* call arch's memory hotadd */
> ret = arch_add_memory(nid, start, size);
>
> if (ret < 0)
> goto error;
>
> /* we online node here. we can't roll back from here. */
> node_set_online(nid);
>
>so we are setting the node online _after_ arch_add_memory but the code
>which adds those sysfs file is called from
>
>arch_add_memory
> __add_pages
> __add_section
> register_new_memory
> register_mem_sect_under_node
> node_online check
Okay, so it turns out the original code ends up creating the sysfs links
not here, but just a little bit afterwards.
add_memory
add_memory_resource
arch_add_memory
[your quoted stack trace above]
...
set_node_online
...
register_one_node
link_mem_sections
register_mem_sect_under_node
The reason they're not getting created now is because
NODE_DATA(nid)->node_spanned_pages = 0 at this point.
link_mem_sections: nid=1, start_pfn=0x10000, end_pfn=0x10000
This is another uninitialized situation, like the one with
node_start_pfn which caused my removal crash. Except here I'm not sure
the correct place to splice in and set it.
--
Reza Arbab
Powered by blists - more mailing lists