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 EEF221DF25C for ; Fri, 13 Mar 2026 13:58:32 +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=1773410313; cv=none; b=GOGVxVh6HEyAHfwEF+w6RoCc34dqHZzDidHQtiGE+KRhs3Uqh1iEDGVvF0TBbB7lwL8usOjMc2bqUTilRX6HBsUhbZSFbY9l388lZtyKUInhcpX+t5966J4k2e3AOpP6H2o385FHxYdT+UVgtTbYo9tpH2YxNKyAITwqZ/B4FZw= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1773410313; c=relaxed/simple; bh=kshVJg/rQTERmOD6YiWVGRVHPpNBvBSWyHEFYDvoDCM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=oY/LIN/L2KClfRqexgWQQ3lM+msp0cOvAZw4859ABckm6OTqq9CQkhNFjkbPSOegRYIH205PvHfZH5hKTJGhiCLOh+L17mnJUggj5rhllxOK8+8tzs7RUb0sQ52YwbqcDnyX/EW9YFZRwrhH5ZLYCIihW25XT/o7+m7rs2LPzoM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=XX4cQHC3; 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="XX4cQHC3" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6B37AC2BC86; Fri, 13 Mar 2026 13:58:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1773410312; bh=kshVJg/rQTERmOD6YiWVGRVHPpNBvBSWyHEFYDvoDCM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=XX4cQHC3W+i3JG5+SggGUb4YhfFkxWFUaZMFpdj6PwCYa/AYmIZ7GxWKHVCjC6gke kuo1XcRg4bXFWt0s13h6QCHyHjxocZ/hbBR1qz12U95YZ7bHoaQXHucQ4tRAKnEvNe oTVLM6qH3rzagaV2SYXufW1SWuhUb0pWrakRUanvW/tN9Ef/G4VSd7h8TtIH4Z3QUE uR4UO6yU89zstZ+6O80qPMIakUZzD3XL87KJcZd03qnO3bEeaibxKh9iWblSBiA5Mp I3hgd4NKR3w//f7qsBtszC8GsY8Vsv5dc8tWhCdkJMIQ3K9DwRxQw7zMQvONCl8FMv KmneJRjsK5wmw== From: Pratyush Yadav To: Michal Clapinski Cc: Evangelos Petrongonas , Pasha Tatashin , Mike Rapoport , Pratyush Yadav , Alexander Graf , Samiullah Khawaja , kexec@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton Subject: Re: [PATCH v6 1/2] kho: fix deferred init of kho scratch In-Reply-To: <20260311125539.4123672-2-mclapinski@google.com> (Michal Clapinski's message of "Wed, 11 Mar 2026 13:55:38 +0100") References: <20260311125539.4123672-1-mclapinski@google.com> <20260311125539.4123672-2-mclapinski@google.com> Date: Fri, 13 Mar 2026 13:58:28 +0000 Message-ID: <2vxz1phnesqj.fsf@kernel.org> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Hi Michal, On Wed, Mar 11 2026, Michal Clapinski wrote: > Currently, if DEFERRED is enabled, kho_release_scratch will initialize > the struct pages and set migratetype of kho scratch. Unless the whole > scratch fit below first_deferred_pfn, some of that will be overwritten > either by deferred_init_pages or memmap_init_reserved_pages. > > To fix it, I initialize kho scratch early and modify every other > path to leave the scratch alone. > > In detail: > 1. Modify deferred_init_memmap_chunk to not initialize kho > scratch, since we already did that. Then, modify deferred_free_pages > to not set the migratetype. Also modify reserve_bootmem_region to skip > initializing kho scratch. > > 2. Since kho scratch is now not initialized by any other code, we have > to initialize it ourselves also on cold boot. On cold boot memblock > doesn't mark scratch as scratch, so we also have to modify the > initialization function to not use memblock regions. > > Signed-off-by: Michal Clapinski I haven't had the time to carefully review this yet, but sharing some high level thoughts. IIUC the real problem isn't struct page initialization, but the fact that if the page is at a pageblock boundary its migrate type is not correctly set to MIGRATE_CMA. So you fix the problem by making sure no one else but KHO can initialize the scratch pages. I think the end result makes the already complicated page initialization sequence even more complicated. I tried to grok that patch and it makes my brain hurt. Can we get away with something simpler? Here's an idea: keep the struct page init the same as it is now, just modify init_pageblock_migratetype() to override the migrate type if page lands in scratch. It already does something similar with MIGRATE_PCPTYPES: if (unlikely(page_group_by_mobility_disabled && migratetype < MIGRATE_PCPTYPES)) migratetype = MIGRATE_UNMOVABLE; So we can also add: /* * Scratch pages are always MIGRATE_CMA since they can't contain * unmovable allocations. */ if (unlikely(pfn_is_kho_scratch(page_to_pfn(page)))) migratetype = MIGRATE_CMA; Do you think this will work? If yes, then I think it is a lot nicer than what this patch is doing. Also, pfn_is_kho_scratch() is pretty much a duplicate of kho_scratch_overlap(). Please pull kho_scratch_overlap() out of kexec_handover_debug.c and use that instead. > --- > My previous idea of marking scratch as CMA late, after deferred struct > page init was done, was bad since allocations can be made before that > and if they land in kho scratch, they become unpreservable. > Such was the case with iommu page tables. [...] -- Regards, Pratyush Yadav