From: Andrea Arcangeli <aarcange@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org
Cc: Mike Rapoport Baoquan He <"rppt@kernel.orgbhe"@redhat.com>,
David Hildenbrand <david@redhat.com>,
Mel Gorman <mgorman@suse.de>, Michal Hocko <mhocko@kernel.org>,
Qian Cai <cai@lca.pw>, Vlastimil Babka <vbabka@suse.cz>,
linux-kernel@vger.kernel.org
Subject: [PATCH 0/1] mm: initialize struct pages in reserved regions outside of the zone ranges
Date: Fri, 4 Dec 2020 20:32:37 -0500 [thread overview]
Message-ID: <20201205013238.21663-1-aarcange@redhat.com> (raw)
In-Reply-To: <20201201181502.2340-1-rppt@kernel.org>
I'm running with these patch applied on all instances as solution to
the compaction crashes that started to trigger after the v5.9
upgrade. It's applied on top of
https://lore.kernel.org/lkml/20201201181502.2340-1-rppt@kernel.org so
that it boots and works fine even when there are memblock.reserved
regions that don't overlap with the memblock.memory (as pfn 0 which is
in memblock.reserved but not added to memblock.memory).
To facilitate any testing:
https://git.kernel.org/pub/scm/linux/kernel/git/andrea/aa.git
===
# grep -A1 -i e820 /proc/iomem
39619000-397f4fff : Unknown E820 type
397f5000-3be55fff : System RAM
DMA zone_start_pfn 0 zone_end_pfn() 4096 contiguous 1
DMA32 zone_start_pfn 4096 zone_end_pfn() 1048576 contiguous 0
Normal zone_start_pfn 1048576 zone_end_pfn() 4909056 contiguous 1
Movable zone_start_pfn 0 zone_end_pfn() 0 contiguous 0
235508 0x397f4000 0x4000000000001000 reserved True pfn_valid True
235509 0x397f5000 0x4000000000000000 reserved False pfn_valid True
===
# grep -A1 -i e820 /proc/iomem
7a17b000-7a216fff : Unknown E820 type
7a217000-7bffffff : System RAM
DMA zone_start_pfn 0 zone_end_pfn() 4096 contiguous 1
DMA32 zone_start_pfn 4096 zone_end_pfn() 1048576 contiguous 0
Normal zone_start_pfn 1048576 zone_end_pfn() 4715392 contiguous 1
Movable zone_start_pfn 0 zone_end_pfn() 0 contiguous 0
500246 0x7a216000 0x3fff000000001000 reserved True pfn_valid True
500247 0x7a217000 0x3fff000000000000 reserved False pfn_valid True
===
I dislike the fix for pfn 0 merged in -mm so that it will still boot
with DEBUG_VM=y, posted in
https://lkml.kernel.org/r/20201203105107.GR123287@linux.ibm.com,
because in addition of looping every 2m from the start at every
memblock for every zone in a O(N*2) way, it'll keep assigning a
"wrong" zoneid to pfn 0 and it literally reintroduces the problem that
https://lore.kernel.org/lkml/20201201181502.2340-1-rppt@kernel.org was
meant to solve.
This patch implements a more significant change since it alters the
zone boundaries.
If there's any problem with extending the zone spans to include
memblock.reserved regions it'd be good to know now, because if there's
no problem with that, I only see benefits in being able to guarantee a
proper zoneid and nid of all struct page that are in reserved
memblocks too and where reserve_bootmem_region will attempt to call
__SetPageReserved later expecting to deal with a "functional" page
structure.
An alternative to this patch, which still sounds preferable than
https://lkml.kernel.org/r/20201203105107.GR123287@linux.ibm.com, is to
just teach reserve_bootmem_region not try to set PageReserved on
uninitialized PagePoison pages and to learn how to deal with "non
functional" page structures, and to just leave them alone. PagePoison
conceptually would act as a NO_ZONEID setting in such case and
orthogonal with all the rest, it'd be nice if it was set also with
DEBUG_VM=n.
Overall anything looks preferable than once again assigning a wrong
zoneid to a page struct that belongs to a pfn that is not part of the
zone in order to boot with the very fix that was meant to prevent such
invariant to be broken in the first place.
I don't think pfn 0 deserves a magic exception and a pass to break the
invariant (even ignoring it may happen that the first pfn in nid > 0
might then also get the pass).
Andrea Arcangeli (1):
mm: initialize struct pages in reserved regions outside of the zone
ranges
include/linux/memblock.h | 17 +++++++++---
mm/debug.c | 3 ++-
mm/memblock.c | 4 +--
mm/page_alloc.c | 57 ++++++++++++++++++++++++++++++++--------
4 files changed, 63 insertions(+), 18 deletions(-)
next prev parent reply other threads:[~2020-12-05 1:34 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-01 18:15 [PATCH] mm: refactor initialization of stuct page for holes in memory layout Mike Rapoport
2020-12-02 23:47 ` Andrew Morton
2020-12-03 6:25 ` Mike Rapoport
2020-12-03 18:34 ` Andrea Arcangeli
2020-12-05 1:32 ` Andrea Arcangeli [this message]
2020-12-05 1:32 ` [PATCH 1/1] mm: initialize struct pages in reserved regions outside of the zone ranges Andrea Arcangeli
2020-12-05 5:10 ` [PATCH 0/1] " Andrew Morton
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=20201205013238.21663-1-aarcange@redhat.com \
--to=aarcange@redhat.com \
--cc="rppt@kernel.orgbhe"@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=cai@lca.pw \
--cc=david@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mgorman@suse.de \
--cc=mhocko@kernel.org \
--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;
as well as URLs for NNTP newsgroup(s).