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

Michal Clapinski posted 2 patches 8 hours ago
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(-)
[PATCH v8 0/2] kho: add support for deferred struct page init
Posted by Michal Clapinski 8 hours ago
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.

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.

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
Re: [PATCH v8 0/2] kho: add support for deferred struct page init
Posted by Mike Rapoport 4 hours ago
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?
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.

> 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

> 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.
Re: [PATCH v8 0/2] kho: add support for deferred struct page init
Posted by Michał Cłapiński 3 hours ago
On Thu, Apr 16, 2026 at 5:00 PM Mike Rapoport <rppt@kernel.org> 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?

> 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.

> > 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.


> > 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.
Re: [PATCH v8 0/2] kho: add support for deferred struct page init
Posted by Mike Rapoport 3 hours ago
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@kernel.org> 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.