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 35C2C435EFE for ; Thu, 13 Aug 2026 11:39:53 +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=1786621194; cv=none; b=ui7ZAucRd4vd//TqNPJrSH0ZyFDYb/95o8oVDWmcVGBnHfT6CEIJzqF+MiYb82/0HIACzOUdlKKzMygTYPm/Yg0Nsml5PfCR13arwehOEWgAARwfVdZPlXpfSm0xCUeyjpZkEUGmsOAphPOBdFBxzlOurjSczndYfDDC//oFRQU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786621194; c=relaxed/simple; bh=4H2hBUaqGZ6UVJzq0bUlLHFMFVwzp6ncH4wHt8/ghMM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=TySSOfzMLw0Ipoz2sXn+UHDiNsb+wJqQtyAN3yINlCXtk01kdg1ov4QCRrn0MWbfL8WvzoO+J4ta2/0Av+EeXpeu3+JWUrs4pJZzYbYSOGmRX6DHdncAV6mqWb+QURXUqupLNqCrpQcnw8j4FKPrVZVHduwxKUY2PFXXEFzwVZs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gp28GzYV; 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="gp28GzYV" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8E8A31F000E9; Thu, 13 Aug 2026 11:39:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1786621192; bh=bzwlkKgAjFA4jPn5mhlQ/drv3ccUTPbHoR0B3kcJtU0=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=gp28GzYV34B/sJAzyVyl+eGvrNb5UuB4gSP85z0eoWa3UUx2NSg2JThEbyxeyPix1 l5G5xD3OpRrw0O7lS/pUWjvs1GloVvb+G00bRgBxHYeE5cIt9SR++oyp1mUnT6AWcR Ie/K++d2vQYE3sWy/XekaKcV2Z+wSEn1Sn4jcFj1C+ze8lVlZLeOEY6vyhhddIqC/W 1V626T0m8H58D9b+4pm10o6UG8i2ojikIvc++n0r656j0p7haiFFlvTgwG4VFroSqZ rR6UbGiTwEwiUX3MQ4aUWaCE2QdmQiOQuiHR96DoHeevN8HP+YeuOdKP+UThYp3KlH PPlJOrwJ4I/ag== Date: Thu, 13 Aug 2026 14:39:46 +0300 From: Mike Rapoport To: Pratyush Yadav Cc: Pranjal Shrivastava , 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 Message-ID: References: <20260803113944.3694290-1-praan@google.com> <2vxzv79f39za.fsf@kernel.org> <2vxzecg33103.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: <2vxzecg33103.fsf@kernel.org> On Wed, Aug 12, 2026 at 03:46:20PM +0200, Pratyush Yadav wrote: > 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. Yes, although when the patches will be a part of the DMA series we might notices something else :) > -- > Regards, > Pratyush Yadav -- Sincerely yours, Mike.