From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id B8DEE21C173 for ; Thu, 16 Apr 2026 15:00:42 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776351642; cv=none; b=biN/C2qxZ6axeU5+lm6QZCciCHuRrtndE9PGoqchiq+Mqi6vca0o4KW3aynhRDIZVeb1OU+Jy8UydaMjjGSY88RHuYlfpjqHspWYSDFSJc5gRvBYhDm9/FTo/xynebkerUu5tS2pIk2b1ec4vfChHOpB4v77yfNHk5y9N0qDeM8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776351642; c=relaxed/simple; bh=JUgUGNgPbhEBAHbcpHrlNrJNbNlPc7RtPYnZIl6AaJs=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Lz3hy6r1iJlc3KRVypYWH8X0nxLov9hMVSUK8GgP6TVOJRw/th5o/6y372EC05JkuJYAynnap1mwHs8uB4ewP5atYF8oxo+T0/3cpplOvcmCZzdgBOELd7uUgmLI5TWLuL8mvou/3553M8BNKM2EpPBLf9zzS5j0qbhglvDyp0o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=UwSbvBSi; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="UwSbvBSi" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 32B3FC2BCAF; Thu, 16 Apr 2026 15:00:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776351642; bh=JUgUGNgPbhEBAHbcpHrlNrJNbNlPc7RtPYnZIl6AaJs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=UwSbvBSi8VF3f3Tq5qpdorKIGcCcVEyMQn5IR0/uhNUFHF44DXbV9J7RD7w2qdGp3 g7H+22JhxJTIT68QSarpWVwYMG6oILD9LlwLOPEcJ90KdS7912K3NJX2ukivcEw21s +e5Oi3qWujsjPr/V8KeFR8iszmfR2eLfsSPe00GI26iidvTiHRmNl8+wuiWJ0YCDGx +I9Xdku6QxtYuUlgrBYG4FfAHUbGwLht+n+vwHGt2EgMlA5ouC6LZ5GDdUpqNehuzw 6ZgOqrJbVuj59hNB9qcd9DpJcBpJlsSoUwJGnOgcqb4bOB0Et4/z6FolG56MMiyb3/ zqIK4vTquolsA== Date: Thu, 16 Apr 2026 18:00:33 +0300 From: Mike Rapoport To: Michal Clapinski Cc: Evangelos Petrongonas , Pasha Tatashin , Pratyush Yadav , Alexander Graf , Samiullah Khawaja , kexec@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton , Vlastimil Babka , Suren Baghdasaryan , Michal Hocko , Brendan Jackman , Johannes Weiner , Zi Yan Subject: Re: [PATCH v8 0/2] kho: add support for deferred struct page init Message-ID: References: <20260416110654.247398-1-mclapinski@google.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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.