From: Andrew Morton <akpm@linux-foundation.org>
To: Qiang Liu <liuq131@chinatelecom.cn>
Cc: rppt@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/mm_init.c: add zidcache to the init_reserved_page function
Date: Wed, 4 Sep 2024 13:41:02 -0700 [thread overview]
Message-ID: <20240904134102.a7171fb6676dd95dc3b8ede7@linux-foundation.org> (raw)
In-Reply-To: <20240904115541.6519-1-liuq131@chinatelecom.cn>
On Wed, 4 Sep 2024 19:55:41 +0800 Qiang Liu <liuq131@chinatelecom.cn> wrote:
> Each call to the init_reserved_page function will look up the
> corresponding zid for the given pfn parameter. Even if subsequent
> calls have the same zid for the pfn as the current one, the lookup
> will be repeated.
>
> During system initialization, the memmap_init_reserved_pages function
> calls init_reserved_page for each contiguous memory region in mem_region.
> Implementing a cache for zid can significantly improve performance.
> Tests have shown that adding a zid cache reduces the execution time of
> the memmap_init_reserved_pages function by over 7%.
>
OK, but how much speedup do we see overall? In other words, is
memmap_init_reserved_pages() a significant consumer of execution time?
I'd be surprised if it makes much difference at all - MAX_NR_ZONES is a
small number. Maybe we call init_reserved_page() a lot.
> --- a/mm/mm_init.c
> +++ b/mm/mm_init.c
> @@ -710,19 +710,25 @@ static void __meminit init_reserved_page(unsigned long pfn, int nid)
> {
> pg_data_t *pgdat;
> int zid;
> + struct zone *zone;
> + static int zidcache;
What locking protects zidcache? lock_device_hotplug() and/or
__init-time serialization? This might be worth mentioning?
>
> if (early_page_initialised(pfn, nid))
> return;
>
> pgdat = NODE_DATA(nid);
>
> - for (zid = 0; zid < MAX_NR_ZONES; zid++) {
> - struct zone *zone = &pgdat->node_zones[zid];
> + zone = &pgdat->node_zones[zidcache];
OK, but if init_reserved_page() was previously called against a
different node, `zidcache' will refer to a zone in a different node.
The code will work OK, but it's worth mentioning somewhere I guess.
> + if (unlikely(zone_spans_pfn(zone, pfn)))
Isn't this wrong? We need to redo the search if !zone_spans_pfn(...)?
> + for (zid = 0; zid < MAX_NR_ZONES; zid++) {
> + zone = &pgdat->node_zones[zid];
>
> - if (zone_spans_pfn(zone, pfn))
> - break;
> - }
> - __init_single_page(pfn_to_page(pfn), pfn, zid, nid);
> + if (zone_spans_pfn(zone, pfn)) {
> + zidcache = zid;
> + break;
> + }
> + }
> + __init_single_page(pfn_to_page(pfn), pfn, zidcache, nid);
> }
> #else
> static inline void pgdat_set_deferred_range(pg_data_t *pgdat) {}
> --
> 2.27.0
parent reply other threads:[~2024-09-04 20:41 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20240904115541.6519-1-liuq131@chinatelecom.cn>]
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=20240904134102.a7171fb6676dd95dc3b8ede7@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=liuq131@chinatelecom.cn \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®