From: Baoquan He <bhe@redhat.com>
To: Mike Rapoport <rppt@kernel.org>
Cc: David Hildenbrand <david@redhat.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
gopakumarr@vmware.com, akpm@linux-foundation.org,
natechancellor@gmail.com, ndesaulniers@google.com,
clang-built-linux@googlegroups.com, rostedt@goodmis.org,
manir@vmware.com, lauyiuch@vmware.com, pjonasson@vmware.com,
rajaramv@vmware.com
Subject: Re: [PATCH 2/2] mm: rename memmap_init() and memmap_init_zone()
Date: Tue, 15 Dec 2020 17:01:33 +0800 [thread overview]
Message-ID: <20201215090133.GB8928@MiWiFi-R3L-srv> (raw)
In-Reply-To: <20201214110448.GB198219@kernel.org>
On 12/14/20 at 01:04pm, Mike Rapoport wrote:
> On Mon, Dec 14, 2020 at 11:00:07AM +0100, David Hildenbrand wrote:
> > On 13.12.20 16:09, Baoquan He wrote:
> > > The current memmap_init_zone() only handles memory region inside one zone.
> > > Actually memmap_init() does the memmap init of one zone. So rename both of
> > > them accordingly.
> > >
> > > And also rename the function parameter 'range_start_pfn' and local variable
> > > 'range_end_pfn' to zone_start_pfn/zone_end_pfn.
> > >
> > > Signed-off-by: Baoquan He <bhe@redhat.com>
> > > ---
......
> > > set_zone_contiguous(zone);
> > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > > index 315c22974f0d..fac599deba56 100644
> > > --- a/mm/page_alloc.c
> > > +++ b/mm/page_alloc.c
> > > @@ -6050,7 +6050,7 @@ overlap_memmap_init(unsigned long zone, unsigned long *pfn)
> > > * (usually MIGRATE_MOVABLE). Besides setting the migratetype, no related
> > > * zone stats (e.g., nr_isolate_pageblock) are touched.
> > > */
> > > -void __meminit memmap_init_zone(unsigned long size, int nid, unsigned long zone,
> > > +void __meminit memmap_init_range(unsigned long size, int nid, unsigned long zone,
> > > unsigned long start_pfn, unsigned long zone_end_pfn,
> > > enum meminit_context context,
> > > struct vmem_altmap *altmap, int migratetype)
> > > @@ -6187,21 +6187,21 @@ static void __meminit zone_init_free_lists(struct zone *zone)
> > > }
> > > }
> > >
> > > -void __meminit __weak memmap_init(unsigned long size, int nid,
> > > +void __meminit __weak memmap_init_zone(unsigned long size, int nid,
> > > unsigned long zone,
> > > - unsigned long range_start_pfn)
> > > + unsigned long zone_start_pfn)
> >
> > Why are we not simply passing "struct zone" like
> >
> > void __meminit __weak memmap_init_zone(struct zone *zone)
> >
> > from which we can derive
> > - nid
> > - zone idx
> > - zone_start_pfn
> > - spanned_pages / zone_end_pfn
> >
> > At least when called from free_area_init_core() this should work just
> > fine I think.
>
> There is also a custom memmap init in ia64 which at least should be
> tested ;-)
Right. Tried in arch/ia64/mm/init.c, the change is as below. Looks
simple, compiling passed on ia64 should be OK.
diff --git a/arch/ia64/mm/init.c b/arch/ia64/mm/init.c
index af678197ac2d..4fa49a762d58 100644
--- a/arch/ia64/mm/init.c
+++ b/arch/ia64/mm/init.c
@@ -541,12 +541,14 @@ virtual_memmap_init(u64 start, u64 end, void *arg)
return 0;
}
-void __meminit
-memmap_init_zone (unsigned long size, int nid, unsigned long zone,
- unsigned long start_pfn)
+void __meminit memmap_init_zone (struct zone *zone)
{
+ unsigned long size = zone->spanned_size;
+ int nid = zone_to_nid(zone), zone_id = zone_idx(zone);
+ unsigned long start_pfn = zone->zone_start_pfn;
+
if (!vmem_map) {
- memmap_init_range(size, nid, zone, start_pfn, start_pfn + size,
+ memmap_init_range(size, nid, zone_id, start_pfn, start_pfn + size,
MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
} else {
struct page *start;
@@ -556,7 +558,7 @@ memmap_init_zone (unsigned long size, int nid, unsigned long zone,
args.start = start;
args.end = start + size;
args.nid = nid;
- args.zone = zone;
+ args.zone = zone_id;
efi_memmap_walk(virtual_memmap_init, &args);
}
>
> More broadly, while Baoquan's fix looks Ok to me, I think we can
> calculate node->first_deferred_pfn earlier in, say,
> free_area_init_node() rather than do defer_init() check for each pfn.
Remember I ever tried to move the defer init up one level into memmap_init()
when making draft patch in the first place. I finally ended up with this
because there's overlap_memmap_init().
>
> > > {
> > > unsigned long start_pfn, end_pfn;
> > > - unsigned long range_end_pfn = range_start_pfn + size;
> > > + unsigned long zone_end_pfn = zone_start_pfn + size;
> > > int i;
> > >
> > > for_each_mem_pfn_range(i, nid, &start_pfn, &end_pfn, NULL) {
> > > - start_pfn = clamp(start_pfn, range_start_pfn, range_end_pfn);
> > > - end_pfn = clamp(end_pfn, range_start_pfn, range_end_pfn);
> > > + start_pfn = clamp(start_pfn, zone_start_pfn, zone_end_pfn);
> > > + end_pfn = clamp(end_pfn, zone_start_pfn, zone_end_pfn);
> > >
> > > if (end_pfn > start_pfn) {
> > > size = end_pfn - start_pfn;
> > > - memmap_init_zone(size, nid, zone, start_pfn, range_end_pfn,
> > > + memmap_init_range(size, nid, zone, start_pfn, zone_end_pfn,
> > > MEMINIT_EARLY, NULL, MIGRATE_MOVABLE);
> > > }
> > > }
> > > @@ -6903,7 +6903,7 @@ static void __init free_area_init_core(struct pglist_data *pgdat)
> > > set_pageblock_order();
> > > setup_usemap(pgdat, zone, zone_start_pfn, size);
> > > init_currently_empty_zone(zone, zone_start_pfn, size);
> > > - memmap_init(size, nid, j, zone_start_pfn);
> > > + memmap_init_zone(size, nid, j, zone_start_pfn);
> > > }
> > > }
> > >
> > >
> >
> >
> > --
> > Thanks,
> >
> > David / dhildenb
> >
>
> --
> Sincerely yours,
> Mike.
>
next prev parent reply other threads:[~2020-12-15 9:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-13 15:09 [PATCH 0/2] Fix the incorrect memmap init defer handling Baoquan He
2020-12-13 15:09 ` [PATCH 1/2] mm: memmap defer init dosn't work as expected Baoquan He
2020-12-13 15:09 ` [PATCH 2/2] mm: rename memmap_init() and memmap_init_zone() Baoquan He
2020-12-14 10:00 ` David Hildenbrand
2020-12-14 11:04 ` Mike Rapoport
2020-12-15 9:01 ` Baoquan He [this message]
2020-12-15 7:18 ` Baoquan He
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=20201215090133.GB8928@MiWiFi-R3L-srv \
--to=bhe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=clang-built-linux@googlegroups.com \
--cc=david@redhat.com \
--cc=gopakumarr@vmware.com \
--cc=lauyiuch@vmware.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=manir@vmware.com \
--cc=natechancellor@gmail.com \
--cc=ndesaulniers@google.com \
--cc=pjonasson@vmware.com \
--cc=rajaramv@vmware.com \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.