From: f00440829 <fanglinxu@huawei.com>
To: <osalvador@suse.de>
Cc: <akpm@linux-foundation.org>, <fanglinxu@huawei.com>,
<linux-mm@kvack.org>, <mhocko@suse.com>,
<pavel.tatashin@microsoft.com>, <vbabka@suse.cz>
Subject: Re: [PATCH] mem-hotplug: fix node spanned pages when we have a node with only zone_movable
Date: Wed, 3 Apr 2019 12:06:07 +0800 [thread overview]
Message-ID: <1554264367-14900-1-git-send-email-fanglinxu@huawei.com> (raw)
In-Reply-To: <20190402145708.7b2xp3cc72vqqlzl@d104.suse.de>
> will actually set zone_start_pfn/zone_end_pfn to the values from node0's
> ZONE_NORMAL?
> So we use clamp to actually check if such values fall within what node1's
> memory spans, and ignore them otherwise?
That's right.
Normally, zone_start_pfn/zone_end_pfn has the same value for all nodes.
Let's look at another example, which is obtained by adding some debugging
information.
e.g.
Zone ranges:
DMA [mem 0x0000000000001000-0x0000000000ffffff]
DMA32 [mem 0x0000000001000000-0x00000000ffffffff]
Normal [mem 0x0000000100000000-0x0000000792ffffff]
Movable zone start for each node
Node 0: 0x0000000100000000
Node 1: 0x00000002b1000000
Node 2: 0x0000000522000000
Early memory node ranges
node 0: [mem 0x0000000000001000-0x000000000009efff]
node 0: [mem 0x0000000000100000-0x00000000bffdefff]
node 0: [mem 0x0000000100000000-0x00000002b0ffffff]
node 1: [mem 0x00000002b1000000-0x0000000521ffffff]
node 2: [mem 0x0000000522000000-0x0000000792ffffff]
Node 0:
node_start_pfn=1 node_end_pfn=2822144
DMA zone_low=1 zone_high=4096
DMA32 zone_low=4096 zone_high=1048576
Normal zone_low=1048576 zone_high=7942144
Movable zone_low=0 zone_high=0
Node 1:
node_start_pfn=2822144 node_end_pfn=5382144
DMA zone_low=1 zone_high=4096
DMA32 zone_low=4096 zone_high=1048576
Normal zone_low=1048576 zone_high=7942144
Movable zone_low=0 zone_high=0
Node 2:
node_start_pfn=5382144 node_end_pfn=7942144
DMA zone_low=1 zone_high=4096
DMA32 zone_low=4096 zone_high=1048576
Normal zone_low=1048576 zone_high=7942144
Movable zone_low=0 zone_high=0
Before this patch, zone_start_pfn/zone_end_pfn in node 0,1,2 is the same:
DMA zone_start_pfn:1 zone_end_pfn:4096
DMA32 zone_start_pfn:4096 zone_end_pfn:1048576
Normal zone_start_pfn:1048576 zone_end_pfn:7942144
Movable zone_start_pfn:0 zone_end_pfn:0
spaned pages resuelt:
node 0:
DMA spanned:4095
DMA32 spanned:1044480
Normal spanned:0
Movable spanned:1773568
totalpages:2559869
node 1:
DMA spanned:0
DMA32 spanned:0
Normal spanned:2560000
Movable spanned:2560000
totalpages:5120000
node 2:
DMA spanned:0
DMA32 spanned:0
Normal spanned:2560000
Movable spanned:2560000
totalpages:5120000
After this patch:
node 0:
DMA zone_start_pfn:1 zone_end_pfn:4096 spanned:4095
DMA32 zone_start_pfn:4096 zone_end_pfn:1048576 spanned:1044480
Normal zone_start_pfn:1048576 zone_end_pfn:2822144 spanned:0
Movable zone_start_pfn:0 zone_end_pfn:0 spanned:1773568
totalpages:2559869
node 1:
DMA zone_start_pfn:4096 zone_end_pfn:4096 spanned:0
DMA32 zone_start_pfn:1048576 zone_end_pfn:1048576 spanned:0
Normal zone_start_pfn:2822144 zone_end_pfn:5382144 spanned:0
Movable zone_start_pfn:0 zone_end_pfn:0 spanned:2560000
totalpages:2560000
node 2:
DMA zone_start_pfn:4096 zone_end_pfn:4096 spanned:0
DMA32 zone_start_pfn:1048576 zone_end_pfn:1048576 spanned:0
Normal zone_start_pfn:5382144 zone_end_pfn:7942144 spanned:0
Movable zone_start_pfn:0 zone_end_pfn:0 spanned:2560000
totalpages:2560000
It is easy to construct such a scenario by configuring kernelcore=mirror
in a multi-NUMA machine without full mirrored memory.
Of course, it can be a machine without any mirrored memory.
A great difference can be observed by startup information and viewing
/proc/pagetypeinfo.
On earlier kernel versions, such BUGs will directly double the memory of
some nodes.
Although these redundant memory exists in the form of reserved memory,
this should not be expected.
prev parent reply other threads:[~2019-04-03 4:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-02 4:11 Linxu Fang
2019-04-02 14:57 ` Oscar Salvador
2019-04-02 15:00 ` Oscar Salvador
2019-04-03 4:06 ` f00440829 [this message]
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=1554264367-14900-1-git-send-email-fanglinxu@huawei.com \
--to=fanglinxu@huawei.com \
--cc=akpm@linux-foundation.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=osalvador@suse.de \
--cc=pavel.tatashin@microsoft.com \
--cc=vbabka@suse.cz \
/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