From: Mike Rapoport <rppt@kernel.org>
To: Michal Clapinski <mclapinski@google.com>
Cc: Evangelos Petrongonas <epetron@amazon.de>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
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>,
Vlastimil Babka <vbabka@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Brendan Jackman <jackmanb@google.com>,
Johannes Weiner <hannes@cmpxchg.org>, Zi Yan <ziy@nvidia.com>
Subject: Re: [PATCH v8 0/2] kho: add support for deferred struct page init
Date: Thu, 16 Apr 2026 18:00:33 +0300 [thread overview]
Message-ID: <aeD5kboEdzwuR4P_@kernel.org> (raw)
In-Reply-To: <20260416110654.247398-1-mclapinski@google.com>
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.
next prev parent reply other threads:[~2026-04-16 15:00 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-16 11:06 [PATCH v8 0/2] kho: add support for deferred struct page init Michal Clapinski
2026-04-16 11:06 ` [PATCH v8 1/2] kho: fix deferred initialization of scratch areas Michal Clapinski
2026-04-16 14:45 ` Mike Rapoport
2026-04-16 15:06 ` Michał Cłapiński
2026-04-16 16:13 ` Mike Rapoport
2026-04-20 13:11 ` Michał Cłapiński
2026-04-21 6:08 ` Mike Rapoport
2026-04-21 10:20 ` Michał Cłapiński
2026-04-22 8:24 ` Mike Rapoport
2026-04-23 8:41 ` Pratyush Yadav
2026-04-16 11:06 ` [PATCH v8 2/2] kho: make preserved pages compatible with deferred struct page init Michal Clapinski
2026-04-16 15:00 ` Mike Rapoport [this message]
2026-04-16 15:23 ` [PATCH v8 0/2] kho: add support for " Michał Cłapiński
2026-04-16 15:43 ` Mike Rapoport
2026-04-20 7:47 ` 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=aeD5kboEdzwuR4P_@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=epetron@amazon.de \
--cc=graf@amazon.com \
--cc=hannes@cmpxchg.org \
--cc=jackmanb@google.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mclapinski@google.com \
--cc=mhocko@suse.com \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--cc=skhawaja@google.com \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--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 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.