From: Mike Rapoport <rppt@linux.ibm.com>
To: Andrea Arcangeli <aarcange@redhat.com>
Cc: Vlastimil Babka <vbabka@suse.cz>,
David Hildenbrand <david@redhat.com>,
Mel Gorman <mgorman@suse.de>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, Qian Cai <cai@lca.pw>,
Michal Hocko <mhocko@kernel.org>,
linux-kernel@vger.kernel.org, Baoquan He <bhe@redhat.com>
Subject: Re: [PATCH 1/1] mm: compaction: avoid fast_isolate_around() to set pageblock_skip on reserved pages
Date: Thu, 26 Nov 2020 12:43:53 +0200 [thread overview]
Message-ID: <20201126104353.GR123287@linux.ibm.com> (raw)
In-Reply-To: <X78jpOqo+IVq1Fn+@redhat.com>
On Wed, Nov 25, 2020 at 10:40:20PM -0500, Andrea Arcangeli wrote:
> On Wed, Nov 25, 2020 at 12:34:41AM -0500, Andrea Arcangeli wrote:
>
> Summary: both old code (missing PG_reserved) and the current code
> (leaving the page struct uninitialized and with wrong nodeid/nid) look
> wrong.
>
> Overall this brings more questions:
>
> - why memblock.reserved exists and isn't automatically calculated as
> inversion of memblock.memory? (or if you prefer: why is the above
> call to memblock_reserve needed to initialize the memory holes?)
memblock.reserved represents memory areas that were allocated before
page allocator is up. This could be memory reported by firmware as
resrved, kernel image, initrd, and any memory kernel allocates before
page allocator is ready.
> - why there's no initialization of the memblock.reserved regions given
> they exists, was it just an oversight? (this one is fixed by Mike's
> patch, although I wish it was possible to drop the function
> memblock_reserve instead)
It was an oversight when I posted
73a6e474cb376921a311786652782155eac2fdf0. I overlooked the fact that x86
does not consider memory allocated by firmware as memory and only parts
of it are considred reserved.
> - what can we do instead of setting the uninitialized nodeid/nid to
> 0,0 and to reliably detect at boot if some page structure within
> zones (but ideally also outside the zone boundary for any pfn where
> pfn_valid returns true) is left uninitialized, as it is happening
> currently on the e820 type 20 range?
I think that we need to fix the e820 and memblock interaction at the
first place. The "non-RAM" holes reported as various types other than
E820_TYPE_RAM are actually seem to be "RAM that firmware grabbed for
itself", so they should be seen by the system as such, like in all other
architectures.
For the regions that cannot be mapped, like those on HPE UV (was it
SGI?) systems, we have MEMBLOCK_NOMAP exactly for that purpose.
Once this is done, we can straihgten logic around memmap intialization
in page_alloc, and I feel it will get simpler that today in the end.
> Thanks,
> Andrea
--
Sincerely yours,
Mike.
prev parent reply other threads:[~2020-11-26 10:44 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-23 21:25 compaction: VM_BUG_ON_PAGE(!zone_spans_pfn(page_zone(page), pfn)) Qian Cai
2020-04-24 3:43 ` Baoquan He
2020-04-24 13:45 ` Qian Cai
2020-05-05 12:43 ` Baoquan He
2020-05-05 13:20 ` Qian Cai
2020-05-11 1:21 ` Baoquan He
2020-04-26 14:41 ` Mike Rapoport
2020-04-27 13:45 ` Qian Cai
2020-11-21 19:45 ` [PATCH 0/1] VM_BUG_ON_PAGE(!zone_spans_pfn) in set_pfnblock_flags_mask Andrea Arcangeli
2020-11-21 19:45 ` [PATCH 1/1] mm: compaction: avoid fast_isolate_around() to set pageblock_skip on reserved pages Andrea Arcangeli
2020-11-21 19:53 ` Andrea Arcangeli
2020-11-23 11:26 ` David Hildenbrand
2020-11-23 13:01 ` Vlastimil Babka
2020-11-24 13:32 ` Mel Gorman
2020-11-24 20:56 ` Andrea Arcangeli
2020-11-25 10:30 ` Mel Gorman
2020-11-25 17:59 ` Andrea Arcangeli
2020-11-26 10:47 ` Mel Gorman
2020-12-06 2:26 ` Andrea Arcangeli
2020-12-06 23:47 ` Mel Gorman
2020-11-25 5:34 ` Andrea Arcangeli
2020-11-25 6:45 ` David Hildenbrand
2020-11-25 8:51 ` Mike Rapoport
2020-11-25 10:39 ` Mel Gorman
2020-11-25 11:04 ` David Hildenbrand
2020-11-25 11:41 ` David Hildenbrand
2020-11-25 18:47 ` Andrea Arcangeli
2020-11-25 13:33 ` Mel Gorman
2020-11-25 13:41 ` David Hildenbrand
2020-11-25 18:28 ` Andrea Arcangeli
2020-11-25 19:27 ` David Hildenbrand
2020-11-25 20:41 ` Andrea Arcangeli
2020-11-25 21:13 ` David Hildenbrand
2020-11-25 21:04 ` Mike Rapoport
2020-11-25 21:38 ` Andrea Arcangeli
2020-11-26 9:36 ` Mike Rapoport
2020-11-26 10:05 ` David Hildenbrand
2020-11-26 17:46 ` Mike Rapoport
2020-11-29 12:32 ` Mike Rapoport
2020-12-02 0:44 ` Andrea Arcangeli
2020-12-02 17:39 ` Mike Rapoport
2020-12-03 6:23 ` Andrea Arcangeli
2020-12-03 10:51 ` Mike Rapoport
2020-12-03 17:31 ` Andrea Arcangeli
2020-12-06 8:09 ` Mike Rapoport
2020-11-26 18:15 ` Andrea Arcangeli
2020-11-26 18:29 ` Andrea Arcangeli
2020-11-26 19:44 ` Mike Rapoport
2020-11-26 20:30 ` Andrea Arcangeli
2020-11-26 21:03 ` Mike Rapoport
2020-11-26 19:21 ` Andrea Arcangeli
2020-11-25 12:08 ` Vlastimil Babka
2020-11-25 13:32 ` David Hildenbrand
2020-11-25 14:13 ` Mike Rapoport
2020-11-25 14:42 ` David Hildenbrand
2020-11-26 10:51 ` Mel Gorman
2020-11-25 19:14 ` Andrea Arcangeli
2020-11-25 19:01 ` Andrea Arcangeli
2020-11-25 19:33 ` David Hildenbrand
2020-11-26 3:40 ` Andrea Arcangeli
2020-11-26 10:43 ` Mike Rapoport [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=20201126104353.GR123287@linux.ibm.com \
--to=rppt@linux.ibm.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--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