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 DC9081E5201 for ; Sun, 31 May 2026 18:40:15 +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=1780252816; cv=none; b=SZvusZFO7tGmCmcjItc7Uk1o+T41v/vj+cO5pAEaQqRaILjKhEqdfv7KYOLEJTcGfPnq/QIpLX6RSo5Sc6RIq730axd01e1vwVY15MXWc4rX9+gGXo+Z5zppLidiSLVeCNEBS/OASYEmOkmaBSDDInAymPtxQlNijD79uypJogs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780252816; c=relaxed/simple; bh=pJ+s/nQtbAKUFnJL0iuE8r/eDSYff9KjG0pz01NrY3I=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=YZwZZZVa3412sxDAIQVJ4Eo2x/OQ+J/Z+zLLBdHPut0JGBEj7SAgbg3kgS6NK/qg3SAGz//cqLaNpoVEYEiwnfDX1pTLF6CndHJZ0nPw6yGk0MW8TPEa7NNzld4X1j3LfrYtM4umLwPc9mNfSxlHw70XCHLVwnXzHH7+k3E25gw= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=EfEXoBUS; 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="EfEXoBUS" Received: by smtp.kernel.org (Postfix) with ESMTPSA id B2C921F00893; Sun, 31 May 2026 18:40:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1780252815; bh=gDniEbMiB4BenIn/IEHnw5RVCpuSrlVy3WIRuPpMhNc=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=EfEXoBUSjPod8EiHuVf9Lmqp1p4/N3NVQlW5lhUe0FyWBvAktt2PWa624j/IOePkn 0Ewu+Agvw+xgJUP1FX3jaxtxBh4l4ZEIHu/P767mkGRGv+d/L0vBSmquJZ0DNd4G2S L0Vw2YD1OmSRoghPver90S6gJIFsTqVfmEIFMKmwtELvbyQRz48Wj/WkWjbuBx62zW NziZEd9RUrErHU38a2ERl7/PFegHNGF2rUikdBUOD3gFdSKn79Z5/9tMz8YG62/lMB x9/lSQ3C4QTa8Nd2lIQi7Tq3/70a0zbjjtGb9wGeAyHy7iEPCmwXeBcBBIhjSl/zPW jwwu4bwp5UgXw== Date: Sun, 31 May 2026 21:40:07 +0300 From: Mike Rapoport To: Pratyush Yadav Cc: Pasha Tatashin , Alexander Graf , Muchun Song , Oscar Salvador , David Hildenbrand , Andrew Morton , Jason Miu , kexec@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 12/12] mm/hugetlb: make bootmem allocation work with KHO Message-ID: References: <20260429133928.850721-1-pratyush@kernel.org> <20260429133928.850721-13-pratyush@kernel.org> <2vxzo6i37bs6.fsf@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: <2vxzo6i37bs6.fsf@kernel.org> On Mon, May 25, 2026 at 05:24:09PM +0200, Pratyush Yadav wrote: > On Sun, May 17 2026, Mike Rapoport wrote: > > On Wed, Apr 29, 2026 at 03:39:14PM +0200, Pratyush Yadav wrote: > >> From: "Pratyush Yadav (Google)" > > So, in summary, I would like to pursue option 1 and try to make it more > appetizing. But I would like to at least know if you hate the "extended > scratch" (ignore the name) as a concept or only the code it results in. Let's retry this one :) I looked more closely, and it seems that mixing SCRATCH and SCRATCH_EXT should be a lesser headache than going with option 4. Tracking the changes in gigantic pages in hugetlb also does not seem something we'd like to pursue especially considering that memory from freed or demoted gigantic pages could be reserved. If we add a dedicated memblock_something to allocate gigantic pages, we can reduce branching in alloc_bootmem() to if (cma) do_cma() else do_memblock() For hugetlb_cma we might want to teach CMA to create pre-allocated areas and then it could reuse the same memblock API. This seems useful even regardless of KHO. -- Sincerely yours, Mike.