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 9043D370D54 for ; Wed, 12 Aug 2026 13:46:23 +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=1786542384; cv=none; b=Dltnk881hitQE/+KEJVielehbmtwDNOZHEFHMGW2ORtX8Rudx/m9spoc6fgHNg6fJ3Mn8QmB92WMjfzAwFYm1WKHxWH87Qq2ioarvJ1/pHVsK0yqd1DT61T3UEODfnnAe2/+LKGQTn8CR6Vr2hhG2r5dU+o9OMep0aT30bhNT7Q= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786542384; c=relaxed/simple; bh=FYaELLdmuxPrCwlLqz299Po8jpwAQvVg0I0pegfo3PU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=mhPx/ND90m+qrH+bJn3CX2mOVQVNX90J38QN4h+8NFyD3YjLfN13Yqdcyo4lykuPUgFQvZV8oL/7BHMCEuQcjNrD0iePhiUsME91z5f6hMkKrSe3m60ZTJj46Bk3h3T2OxFXwipc1Wx5t6Fq8EUHjmMyoz7mz6zHuhqHcsLCUEA= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=TQWM28p4; 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="TQWM28p4" Received: by smtp.kernel.org (Postfix) with ESMTPSA id BBD321F000E9; Wed, 12 Aug 2026 13:46:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786542383; bh=jmvyDkK0SEMV+6hHSi9U54dzAcSRibYyWNZkwQf61Gs=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=TQWM28p48UmnPpZTJo7OBBfMPXCQoOnJggGChZDveP5NohAsVU4NOdN8vluuJI62P C5VH3XAhyXK9qQxsUmIF1KBtPh6faVdjusm0tirQscBfl0s+Pt26UgSqeySQ2b8S+V MHTHaCFcsmmq1ysujL71P+gSIK5GJ9R6JMyUhoC1b6dW6lOH7VebDXE4ROaHPxIfkL tHAp4JrfgRzx/OvY9v3ExhWN4Z3OwqKh0H6EQ24OhO/8ippvHUPE2rqwwBxczUSMGt f98RZBZVY5ei1fo1Usxgq5O3GjAxiHAIqyK1uvyHVa2kbxC2Wrwir0CjTCmTbZPzf0 eNvdIGAjTpDEQ== From: Pratyush Yadav To: Pranjal Shrivastava Cc: Pratyush Yadav , Mike Rapoport , Pasha Tatashin , 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 In-Reply-To: (Pranjal Shrivastava's message of "Wed, 12 Aug 2026 12:49:00 +0000") References: <20260803113944.3694290-1-praan@google.com> <2vxzv79f39za.fsf@kernel.org> Date: Wed, 12 Aug 2026 15:46:20 +0200 Message-ID: <2vxzecg33103.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 Wed, Aug 12 2026, Pranjal Shrivastava wrote: > On Wed, Aug 12, 2026 at 12:32:25PM +0200, Pratyush Yadav wrote: >> On Tue, Aug 11 2026, Mike Rapoport wrote: >> >> > 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. >> >> Makes sense I think. We can review the patches here, but then they can >> go in with the DMA series. >> > > So.. IIUC, I'll post a v5 here as a standalone series till we get > consensus, and finally the reviewed patches can be folded with the DMA > series? That sounds good to me at least. -- Regards, Pratyush Yadav