On 12.02.21 11:33, Michal Hocko wrote:
On Mon 08-02-21 13:08:20, Mike Rapoport wrote:
From: Mike Rapoport <rppt@xxxxxxxxxxxxx>
There could be struct pages that are not backed by actual physical memory.
This can happen when the actual memory bank is not a multiple of
SECTION_SIZE or when an architecture does not register memory holes
reserved by the firmware as memblock.memory.
Such pages are currently initialized using init_unavailable_mem() function
that iterates through PFNs in holes in memblock.memory and if there is a
struct page corresponding to a PFN, the fields of this page are set to
default values and it is marked as Reserved.
init_unavailable_mem() does not take into account zone and node the page
belongs to and sets both zone and node links in struct page to zero.
IIUC the zone should be associated based on the pfn and architecture
constraines on zones. Node is then guessed based on the last existing
range, right?
On a system that has firmware reserved holes in a zone above ZONE_DMA, for
instance in a configuration below:
# grep -A1 E820 /proc/iomem
7a17b000-7a216fff : Unknown E820 type
7a217000-7bffffff : System RAM
I like the description here though. Thanks very useful.
unset zone link in struct page will trigger
VM_BUG_ON_PAGE(!zone_spans_pfn(page_zone(page), pfn), page);
I guess you mean set_pfnblock_flags_mask, right? Is this bug on really
needed? Maybe we just need to skip over reserved pages?
because there are pages in both ZONE_DMA32 and ZONE_DMA (unset zone link
in struct page) in the same pageblock.
Moreover, it is possible that the lowest node and zone start is not aligned
to the section boundarie, for example on x86:
[ 0.078898] Zone ranges:
[ 0.078899] DMA [mem 0x0000000000001000-0x0000000000ffffff]
...
[ 0.078910] Early memory node ranges
[ 0.078912] node 0: [mem 0x0000000000001000-0x000000000009cfff]
[ 0.078913] node 0: [mem 0x0000000000100000-0x000000003fffffff]
and thus with SPARSEMEM memory model the beginning of the memory map will
have struct pages that are not spanned by any node and zone.
Update detection of node boundaries in get_pfn_range_for_nid() so that the
node range will be expanded to cover memory map section. Since zone spans
are derived from the node span, there always will be a zone that covers the
part of the memory map with unavailable pages.
Interleave initialization of the unavailable pages with the normal
initialization of memory map, so that zone and node information will be
properly set on struct pages that are not backed by the actual memory.
I have to digest this but my first impression is that this is more heavy
weight than it needs to. Pfn walkers should normally obey node range at
least. The first pfn is usually excluded but I haven't seen real
We've seen examples where this is not sufficient. Simple example:
Have your physical memory end within a memory section. Easy via QEMU,
just do a "-m 4000M". The remaining part of the last section has
fake/wrong node/zone info.
Hotplug memory. The node/zone gets resized such that PFN walkers might
stumble over it.
The basic idea is to make sure that any initialized/"online" pfn belongs
to exactly one node/zone and that the node/zone spans that PFN.
problems with that. The VM_BUG_ON blowing up is really bad but as said
above we can simply make it less offensive in presence of reserved pages
as those shouldn't reach that path AFAICS normally.
Andrea tried tried working around if via PG_reserved pages and it
resulted in quite some ugly code. Andrea also noted that we cannot rely
on any random page walker to do the right think when it comes to messed
up node/zone info.
--
Thanks,
David / dhildenb
