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 30B59438464 for ; Tue, 11 Aug 2026 10:27:12 +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=1786444036; cv=none; b=RA6ALNRNBw6n7my7e29UwuELgxfwKPyB8QaDueZ2BbA0sgBzTvr4YDYoWgFONhp6Y+h5fKP97nxW6YNx2fLIwNgkIbAj0ImxQTgLwAAGH7fKWGsdBQxH7dLRJbSNIqMz0KipJRWfOkG2o1r+IVh/dWY8C3cOvV91b4aKUgqZxFg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786444036; c=relaxed/simple; bh=aStyiLSUN4yC/NxW29T2Y3eNJt7pLaAlkRBfQ39CnwY=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=QE/A84ersfD7Txb6qJjgHLPz1O8kb8wZNPc6so7eH431SHnCXiRRFwCPTGZg0rlwVkxM2TG1tWkgcXjCl/52G09wEkCKp/5PHDHm3LXC/Ups9ZICaVYfTdYpy0C9jj1dEPNL/swHv/eV1aQyKZd6vZ73067D3Di0JBRh4pdRzNo= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=oaG9JOuX; 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="oaG9JOuX" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6C69E1F000E9; Tue, 11 Aug 2026 10:27:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786444031; bh=1kXXh8PYIfsaZmMaidvXBBrRKRtqDnrYuD5GOCyydIk=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=oaG9JOuX/0vcBfIckuFTx0W15YPUcXCkJnkcQjMIbr0AOcvnRtL0pLoDIAript9S5 fvsQp8kNlISsYrcm5UCUZ4SUOLxshJUgfj26E8vKd2lAx74cQDzRVPevMviHGIMdVv EgJjlP6Wz0Ayg7/ts/UeqsCKHQESAC+awlHAHhcpRnWTStKseu8NMxYTkE8R/VTz4v GakfJG9VtthV8QjjqYYAeOBe2uBY3IDnsjz/PmL1jmZkHj3Kr9VTBdMU6Qay7ioC2Q G9+2+aCFeO8ej69JItG0DCUlPp/k2q9njH+oEzPqW42l3pEdl6LV6pkscYGwajURgk JocxcWXRiS5GQ== Date: Tue, 11 Aug 2026 13:27:04 +0300 From: Mike Rapoport To: Pranjal Shrivastava Cc: Pasha Tatashin , Pratyush Yadav , Alexander Graf , Samiullah Khawaja , David Matlack , kexec@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH v4 0/2] kho: support preserving high-order non-compound pages Message-ID: References: <20260803113944.3694290-1-praan@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: <20260803113944.3694290-1-praan@google.com> Hi Pranjal, On Mon, Aug 03, 2026 at 11:39:41AM +0000, Pranjal Shrivastava wrote: > Introduction > ============ > This series is required for the ongoing effort to preserve DMA allocations > across KHO [1]. It addresses a fundamental mismatch between the current KHO > restoration logic and the physical reality of high-order buddy allocations. I skimmed through the patches, they look fine to me before the in-depth review :) But we are really close to the merge window, so we'll anyway need to reiterate after v7.3-rc1. > The Problem > =========== > The current KHO restore implementation treats all multi-page blocks as > split pages during restoration. Specifically, kho_restore_pages() > initializes every 4KB sub-page with a refcount of 1. > > However, many kernel subsystems, most notably the DMA allocator (via > dma_alloc_coherent), frequently return high-order non-compound pages. > In this state, only the head page carries a refcount of 1, while > all tail pages have a refcount of 0. This hints that these patches could be a part of the DMA preservation series, unless you expect other users of the new API. Generally, we don't merge new APIs without the users and if DMA preservation is the only user, it's better to fold these two patches there. -- Sincerely yours, Mike.