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 122D83624C5 for ; Thu, 16 Apr 2026 09:44:10 +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=1776332651; cv=none; b=A4n7byaPUP8UplOEzRxEq9Pit8Px1cPq0SwTDcop2Ko49il4LuPO/MfJ/EBBM6xJuAIsONz1e7JE78SZ/lrfYT6foefeYJ4J2NVB4O9MRuGpPkAYw3Hi4caxbOlTXjqmkx5sa2Meo0RRM+gMN6AAF8JIgxe5E1SJEKmN2lCB/lk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1776332651; c=relaxed/simple; bh=CPSWvjITVlDgLqJaNBJ4mUklmtrmxg+VXMXbQXCouI0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=Oq2MMivB2GRNlCvh5p3pFbGTgrTSGqcPEkqfXMAy6QRoF1uJT+9lkTISNwoN6HxZzoZ6/J4EpSiWHc1mZ/8pUV3vMErxqap/TqCOdghNU6czt1yltNXY1oHYlQYtYnZZ263Rk2H+8fWYSvqt0wxXW6egisYsSL9yA15uSCHHe+Y= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=naarDjEy; 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="naarDjEy" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4A991C2BCAF; Thu, 16 Apr 2026 09:44:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1776332650; bh=CPSWvjITVlDgLqJaNBJ4mUklmtrmxg+VXMXbQXCouI0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=naarDjEyGSJoW4LnTL4F2XkqZixsO54podpGe54idT5LI8xKd9lFol6POyM9EjwyS HjZsccyA4hqkKhLkrYCnoqCfkUa0DlTmc/CeJnpiLKHlNmBtzxHFpZepRWmzlbGiSL 6Ne/oUuxTDNJgwK/UpkYdnUuJScKVNdxzdQSH8xVfbgM9t5Mu0SXmZQGKv+wfHLWUv W8/alr94CH26BOTOvpFAhpeXQ77+8RXwF8KoNd5n8hPwv9JC7u88P/yzdtWlbJQ6zb nV05JT4Q4zSuYVxFN9IExOz/LY9yI5Oi9bhQDEoX6kf1oZ3Owy6AgzcfwFij3w3tfJ 17PuGeGbNQdpg== From: Pratyush Yadav To: Zi Yan Cc: Pratyush Yadav , Mike Rapoport , =?utf-8?B?TWljaGHFgiBDxYJhcGnFhHNraQ==?= , Evangelos Petrongonas , Pasha Tatashin , Alexander Graf , Samiullah Khawaja , kexec@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Andrew Morton Subject: Re: [PATCH v7 2/3] kho: fix deferred init of kho scratch In-Reply-To: (Zi Yan's message of "Tue, 07 Apr 2026 09:21:25 -0400") References: <20260317141534.815634-3-mclapinski@google.com> <76559EF5-8740-4691-8776-0ADD1CCBF2A4@nvidia.com> <0D1F59C7-CA35-49C8-B341-32D8C7F4A345@nvidia.com> <58A8B1B4-A73B-48D2-8492-A58A03634644@nvidia.com> <2vxzwlyj9d0b.fsf@kernel.org> Date: Thu, 16 Apr 2026 09:44:06 +0000 Message-ID: <2vxzjyu76xzt.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 On Tue, Apr 07 2026, Zi Yan wrote: > On 7 Apr 2026, at 8:21, Pratyush Yadav wrote: [...] >> Hmm, I don't like that how complex this is. It adds another layer of >> complexity to the initialization of the migratetype, and you have to dig >> through all the possible call sites to be sure that we catch all the >> cases. Makes it harder to wrap your head around it. Plus, makes it more >> likely for bugs to slip through if later refactors change some page init >> flow. >> >> Is the cost to look through the scratch array really that bad? I would >> suspect we'd have at most 4-6 per-node scratches, and one global one >> lowmem. So I'd expect around 10 items to look through, and it will >> probably be in the cache anyway. > > It is not only about the cost of going through the scratch array, but also > about adding kho code to the generic init_pageblock_migratetype(). > This means all callers of init_pageblock_migratetype(), no matter if > they are involved with kho or not, need to do the check. It is a good > practice to do the check when necessary, otherwise, this catch-all check > might hide some bugs in the future. We can move the check to memmap init, so it will still be done for most pageblocks I reckon. The only other callers I see are zone device and CMA. Anyway, I get your point and am fine with moving it out to memmap init functions. [...] -- Regards, Pratyush Yadav