Re: [PATCH v8 0/2] kho: add support for deferred struct page init

[Mike Rapoport]

On Thu, Apr 16, 2026 at 05:23:32PM +0200, Michał Cłapiński wrote:
> On Thu, Apr 16, 2026 at 5:00 PM Mike Rapoport <rppt@xxxxxxxxxx> wrote:
> >
> > On Thu, Apr 16, 2026 at 01:06:52PM +0200, Michal Clapinski wrote:
> > > When CONFIG_DEFERRED_STRUCT_PAGE_INIT is enabled, struct page
> > > initialization is deferred to parallel kthreads that run later in
> > > the boot process.
> > >
> > > Currently, KHO is incompatible with DEFERRED.
> > > This series fixes that incompatibility.
> > > ---
> > > v8:
> > > - moved overriding the migratetype from init_pageblock_migratetype
> > >   to callsites
> > > v7:
> > > - reimplemented the initialization of kho scratch again
> > > v6:
> > > - reimplemented the initialization of kho scratch
> > > v5:
> > > - rebased
> > > v4:
> > > - added a new commit to fix deferred init of kho scratch
> > > - switched to ulong when refering to pfn
> > > v3:
> > > - changed commit msg
> > > - don't invoke early_pfn_to_nid if CONFIG_DEFERRED_STRUCT_PAGE_INIT=n
> > > v2:
> > > - updated a comment
> > >
> > > I took Evangelos's test code:
> > > https://git.infradead.org/?p=users/vpetrog/linux.git;a=shortlog;h=refs/heads/kho-deferred-struct-page-init
> > > and then modified it to this monster test that does 2 allocations:
> > > at core_initcall (early) and at module_init (late). Then kexec, then
> > > 2 more allocations at these points, then restore the original 2, then
> > > kexec, then restore the other 2. Basically I test preservation of early
> > > and late allocation both on cold and on warm boot.
> > > Tested it both with and without DEFERRED.
> >
> > Any chance you can clean that monster and send it as patch 3?
> 
> I fear that would delay this series somewhere into v15, which I would
> like to avoid. Can I clean it up and send it separately?

I don't mind. For this series can we add a build with deferred pages to
selftests/kho/vmtest.sh? Shouldn't be as controversial :)
 
> > There's no real difference between core_initcall() and module_init() with
> > respect to that deferred page initialization, they both run after the
> > memory map is fully initialized.
> 
> One of them runs before kho_init() and the other after. So it allowed
> me to expose the bug that I introduced in v4.
 
Ah, nice.

> > > This patch probably doesn't apply onto anything currently.
> > > It's based on mm-new with
> > > "memblock: move reserve_bootmem_range() to memblock.c and make it static"
> > > cherrypicked from rppt/memblock.
> >
> > You can base on for-next in the memblock tree:
> > https://git.kernel.org/pub/scm/linux/kernel/git/rppt/memblock
> 
> I tried that but that branch is missing other commits from mm-new. So
> I would have to modify my code, which would then conflict with mm-new.

Let's continue with mm-new and a cherrypicked memblock patch, it all should
be sorted out after -rc1 I hope.
 
> > > Evangelos Petrongonas (1):
> > >   kho: make preserved pages compatible with deferred struct page init
> > >
> > > Michal Clapinski (1):
> > >   kho: fix deferred initialization of scratch areas
> > >
> > >  include/linux/memblock.h           |  7 ++--
> > >  kernel/liveupdate/Kconfig          |  2 --
> > >  kernel/liveupdate/kexec_handover.c | 52 +++++++++++++++---------------
> > >  mm/memblock.c                      | 41 +++++++++++------------
> > >  mm/mm_init.c                       | 27 +++++++++++-----
> > >  5 files changed, 69 insertions(+), 60 deletions(-)
> > >
> > > --
> > > 2.54.0.rc1.555.g9c883467ad-goog
> > >
> >
> > --
> > Sincerely yours,
> > Mike.

-- 
Sincerely yours,
Mike.