From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 DE9CE43F0A0 for ; Tue, 28 Jul 2026 13:35:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785245754; cv=none; b=PHkk9iFAfkN+a4YHgSpFT1CXRVLHxQdXL0ZrGl3DwP+kbm0rzxfDtOuqHawkM4n+iyS1P4tnQBNxKgG0NkYiY/jdqx5D3R8Vs+QvsPW80qQQ20BXlC67X65EBmv0rjnaAJvSzbjbpXIPmq4Zt/R8dY30cfOaO7ycwxHo2LvGRoA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785245754; c=relaxed/simple; bh=eImMZSC8yWEwd5DtGqxWkNGurg9AEB+yNLkVIiOjZ10=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=UiTDvDwdo2z176NDWH9b5ZoZvttBY9IHpaa7oR4XdkSCbByhe3dwHV1VrJgiAuIHWpr9EN3+1N3Nx8oroJmFDkK3K+F1jk3Vgeo3OaYqmPknDWjDKWIjCB+9AW/emtXa9/ALwUYnkLoQ2iU/261oRNx6rF793gSWbwxKK3BdtCo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=hJ6ZyGrX; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="hJ6ZyGrX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4F6F61F000E9; Tue, 28 Jul 2026 13:35:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1785245749; bh=F7E60EEGx3HhYQLCew9dec70QQpFr1JD3ItgZk/3IBg=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=hJ6ZyGrXFohV282rb4DcBTZtLaXEm4DG4EzBSaAk21cm4cHuYoe24V2bP2A3XjLTX 7/D8dj15R5W/TNZgNi8iJNfMD6iu4ysPmFfd67MHL87sKSj/quy+1zpDftRPgID1md W1Dg46CjtdpalY9SmavmC1shWHb2XACiP+0fjTLovQV4x9EzRnu4pwlZkM0prax1iI IYZfhTDMOXUzqcjDzb79D/1mBLqK9/xMKVSgLT4zm79An4+G6SLphQoJHGp/ayHn7Y NHm/DiPdusfbad3D4k8lq9K3yZREeduP64s/aoQP0iA/h7DLaYue/b4dvGjVmFeSuv erXV/LxzbgXtA== Date: Tue, 28 Jul 2026 16:35:41 +0300 From: Mike Rapoport To: Pratyush Yadav Cc: Pasha Tatashin , Alexander Graf , Muchun Song , Oscar Salvador , David Hildenbrand , Andrew Morton , Jason Miu , Jork Loeser , kexec@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 00/21] kho: make boot time huge page allocation work nicely with KHO Message-ID: References: <20260725172133.4018491-1-pratyush@kernel.org> 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: <20260725172133.4018491-1-pratyush@kernel.org> On Sat, Jul 25, 2026 at 07:21:00PM +0200, Pratyush Yadav wrote: > From: "Pratyush Yadav (Google)" > > Hi, > > Gigantic huge page allocation is somewhat broken currently with KHO. > > First, they break scratch size accounting. Since they are allocated > using the memblock alloc APIs, they count towards RSRV_KERN, and this > scratch size when using scratch_scale. This means if huge pages take a > large enough chunk of system memory scratch size will blow up and fail > to allocate. > > Second, scratch can not contain preserved memory, and if hugepages are > allocated from scratch, they will fail to be preserved with the upcoming > hugetlb preservation series [0]. > > Fix this by introducing the concept of extended scratch areas. They are > areas that the kernel discovers on boot by walking the radix tree and > finding free memory ranges. See patch 10 for more details. > > Muchun Song (1): > mm/mm_init: simplify deferred_free_pages() migratetype init > > Pratyush Yadav (Google) (20): > kho: generalize radix tree APIs > kho: make radix max key width more obvious > kho: disallow wide keys in radix tree > kho: return virtual address of mem_map from kho_get_mem_map() > kho: store incoming radix tree in kho_in > kho: move all memory retrieval logic to kho_mem_retrieve() > kho: add a struct for radix callbacks > kho: add callback for table pages > kho: add data argument to radix walk callback > kho: allow early-boot usage of the KHO radix tree > kho: allow destroying KHO radix tree > kho: add kho_radix_init_tree() > kho: expose kho_scratch_overlap() to kexec_handover.h > kho: initialize kho_scratch pointer earlier in boot > kho: initialize preserved memory map radix tree earlier > mm/mm_init: don't rely on memblock to get KHO scratch migratetype > kho: extend scratch > memblock: make HugeTLB bootmem allocation work with KHO > memblock: add memblock_reserved_hugetlb_size() > kho: exclude hugetlb memory from scratch size calculation I added it to the liveupdate tree. Please take a look at Sashiko comments, we might need v5 if it has valid (not pre-existing) points. -- Sincerely yours, Mike.