From: "Michał Cłapiński" <mclapinski@google.com>
To: Zi Yan <ziy@nvidia.com>
Cc: Evangelos Petrongonas <epetron@amazon.de>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Mike Rapoport <rppt@kernel.org>,
Pratyush Yadav <pratyush@kernel.org>,
Alexander Graf <graf@amazon.com>,
Samiullah Khawaja <skhawaja@google.com>,
kexec@lists.infradead.org, linux-mm@kvack.org,
linux-kernel@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH v7 2/3] kho: fix deferred init of kho scratch
Date: Wed, 18 Mar 2026 16:45:25 +0100 [thread overview]
Message-ID: <CAAi7L5ex+66qgFzRkLDbuOmC=cVrMyBctPZv6wd15n1rc2U9KQ@mail.gmail.com> (raw)
In-Reply-To: <76559EF5-8740-4691-8776-0ADD1CCBF2A4@nvidia.com>
On Wed, Mar 18, 2026 at 4:26 PM Zi Yan <ziy@nvidia.com> wrote:
>
> On 18 Mar 2026, at 11:18, Michał Cłapiński wrote:
>
> > On Wed, Mar 18, 2026 at 4:10 PM Zi Yan <ziy@nvidia.com> wrote:
> >>
> >> On 17 Mar 2026, at 10:15, Michal Clapinski wrote:
> >>
> >>> Currently, if DEFERRED is enabled, kho_release_scratch will initialize
> >>> the struct pages and set migratetype of kho scratch. Unless the whole
> >>> scratch fit below first_deferred_pfn, some of that will be overwritten
> >>> either by deferred_init_pages or memmap_init_reserved_pages.
> >>>
> >>> To fix it, I modified kho_release_scratch to only set the migratetype
> >>> on already initialized pages. Then, modified init_pageblock_migratetype
> >>> to set the migratetype to CMA if the page is located inside scratch.
> >>>
> >>> Signed-off-by: Michal Clapinski <mclapinski@google.com>
> >>> ---
> >>> include/linux/memblock.h | 2 --
> >>> kernel/liveupdate/kexec_handover.c | 10 ++++++----
> >>> mm/memblock.c | 22 ----------------------
> >>> mm/page_alloc.c | 7 +++++++
> >>> 4 files changed, 13 insertions(+), 28 deletions(-)
> >>>
> >>
> >> <snip>
> >>
> >>> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> >>> index ee81f5c67c18..5ca078dde61d 100644
> >>> --- a/mm/page_alloc.c
> >>> +++ b/mm/page_alloc.c
> >>> @@ -55,6 +55,7 @@
> >>> #include <linux/cacheinfo.h>
> >>> #include <linux/pgalloc_tag.h>
> >>> #include <linux/mmzone_lock.h>
> >>> +#include <linux/kexec_handover.h>
> >>> #include <asm/div64.h>
> >>> #include "internal.h"
> >>> #include "shuffle.h"
> >>> @@ -549,6 +550,12 @@ void __meminit init_pageblock_migratetype(struct page *page,
> >>> migratetype < MIGRATE_PCPTYPES))
> >>> migratetype = MIGRATE_UNMOVABLE;
> >>>
> >>> + /*
> >>> + * Mark KHO scratch as CMA so no unmovable allocations are made there.
> >>> + */
> >>> + if (unlikely(kho_scratch_overlap(page_to_phys(page), PAGE_SIZE)))
> >>> + migratetype = MIGRATE_CMA;
> >>> +
> >>
> >> If this is only for deferred init code, why not put it in deferred_free_pages()?
> >> Otherwise, all init_pageblock_migratetype() callers need to pay the penalty
> >> of traversing kho_scratch array.
> >
> > Because reserve_bootmem_region() doesn't call deferred_free_pages().
> > So I would also have to modify it.
> >
> > And the early initialization won't pay the penalty of traversing the
> > kho_scratch array, since then kho_scratch is NULL.
>
> How about hugetlb_bootmem_init_migratetype(), init_cma_pageblock(),
> init_cma_reserved_pageblock(), __init_page_from_nid(), memmap_init_range(),
> __init_zone_device_page()?
>
> 1. are they having any PFN range overlapping with kho?
> 2. is kho_scratch NULL for them?
>
> 1 tells us whether putting code in init_pageblock_migratetype() could save
> the hassle of changing all above locations.
> 2 tells us how many callers are affected by traversing kho_scratch.
I could try answering those questions but
1. I'm new to this and I'm not sure how correct the answers will be.
2. If you're not using CONFIG_KEXEC_HANDOVER, the performance penalty
will be zero.
If you are using it, currently you have to disable
CONFIG_DEFERRED_STRUCT_PAGE_INIT and the performance hit from this is
far, far greater. This solution saves 0.5s on my setup (100GB of
memory). We can always improve the performance further in the future.
> Thanks.
>
> Best Regards,
> Yan, Zi
next prev parent reply other threads:[~2026-03-18 15:45 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-17 14:15 [PATCH v7 0/3] kho: add support for deferred struct page init Michal Clapinski
2026-03-17 14:15 ` [PATCH v7 1/3] kho: make kho_scratch_overlap usable outside debugging Michal Clapinski
2026-03-18 9:16 ` Mike Rapoport
2026-04-07 10:55 ` Pratyush Yadav
2026-04-07 14:18 ` Pasha Tatashin
2026-04-07 16:09 ` Pratyush Yadav
2026-04-07 16:32 ` Pasha Tatashin
2026-03-17 14:15 ` [PATCH v7 2/3] kho: fix deferred init of kho scratch Michal Clapinski
2026-03-17 23:23 ` Vishal Moola (Oracle)
2026-03-18 0:08 ` SeongJae Park
2026-03-18 0:23 ` Andrew Morton
2026-03-18 9:33 ` Mike Rapoport
2026-03-18 10:28 ` Michał Cłapiński
2026-03-18 10:33 ` Michał Cłapiński
2026-03-18 11:02 ` Mike Rapoport
2026-03-18 15:10 ` Zi Yan
2026-03-18 15:18 ` Michał Cłapiński
2026-03-18 15:26 ` Zi Yan
2026-03-18 15:45 ` Michał Cłapiński [this message]
2026-03-18 17:08 ` Zi Yan
2026-03-18 17:19 ` Michał Cłapiński
2026-03-18 17:36 ` Zi Yan
2026-03-19 7:54 ` Mike Rapoport
2026-03-19 18:17 ` Michał Cłapiński
2026-03-22 14:45 ` Mike Rapoport
2026-04-07 12:21 ` Pratyush Yadav
2026-04-07 13:21 ` Zi Yan
2026-03-17 14:15 ` [PATCH v7 3/3] kho: make preserved pages compatible with deferred struct page init Michal Clapinski
2026-03-17 17:46 ` [PATCH v7 0/3] kho: add support for " Andrew Morton
2026-03-18 9:34 ` Mike Rapoport
2026-03-18 9:18 ` Mike Rapoport
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='CAAi7L5ex+66qgFzRkLDbuOmC=cVrMyBctPZv6wd15n1rc2U9KQ@mail.gmail.com' \
--to=mclapinski@google.com \
--cc=akpm@linux-foundation.org \
--cc=epetron@amazon.de \
--cc=graf@amazon.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--cc=rppt@kernel.org \
--cc=skhawaja@google.com \
--cc=ziy@nvidia.com \
/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