From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f169.google.com (mail-pl1-f169.google.com [209.85.214.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5ABC224293C for ; Wed, 8 Jul 2026 17:05:27 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.169 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783530328; cv=none; b=f5XkUIj5YGnoK0YczvBbFUEAoPKhdTZzli7wYKYPNyDW/bw6RXfIaxczUzRjRrVB/xyJsujDu24It9vNPhu/CQL+yQciRnkr+aONpethl9tg7DyodheAU96D9smlcinAouO/rZ8l97b/plHK80Hk5/UphNyw57Q1cYSYtA4a328= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783530328; c=relaxed/simple; bh=GCQS504LklICt9V1vET3N+eQhaQirhtejwY/XcXmOaM=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=BCGZ19Jfo8oODvp4+Iscv/eZIryOz8CHI7S+2h2vZQTYf2rv5tJavgWzrip7/ZyRBgE/vvTvgthMPD1i9QVFh9ahSD7Yv50zUBXNbVbz9W7Z8Z6KpmYfYeEondiffNSwxR/30POvBE8zscppugfWPk0TQrb2WA50Eg+sv8Umr6o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=qKLXoPHP; arc=none smtp.client-ip=209.85.214.169 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="qKLXoPHP" Received: by mail-pl1-f169.google.com with SMTP id d9443c01a7336-2cacef7d299so785ad.1 for ; Wed, 08 Jul 2026 10:05:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1783530326; x=1784135126; darn=vger.kernel.org; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:from:to:cc:subject :date:message-id:reply-to:content-type; bh=HMed8Aal2XzeNAdRp76BDF3jCpjJx/NH7JDMMBYScHA=; b=qKLXoPHPuEl4+obFvzHGLAi0bNpJvUexPps14Vei80YXDt+cVZd7EnuXSI1C9QQ4dR 2ApFdLIYtzdmLCIguNylD1dnzEXjjEP8BKo1ZHKTViN12tllpF2EvK6ZXdI4pgFiD4/k lC9gtuP/Z0tk2KD4M/mfdr2ymDOUU8D8TojCce3jrO6EvDvN6fCvpvkcF6DCuZB3pIS2 SEzWVb/ouIIVxk0mT9ywYz6Lq5VU1vtQWqdJvHp1TXotKZqP9PS0oeCP5amWlDGloXx2 yjz8oYwPs/PNXObos/FCDCgAYBJz3gIMN4Opa1U6zaLA5Mv7Uyanv5dsn+taKs6xqZH7 47cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783530326; x=1784135126; h=in-reply-to:content-disposition:content-type:mime-version :references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=HMed8Aal2XzeNAdRp76BDF3jCpjJx/NH7JDMMBYScHA=; b=KxMh8/DV/uG6oQEBoN1cbJ3rFy/Cvqa7LctAf94KPKKoImP9CX7TleOG0WJ4FJ+WTP 5q6KRD1zispkbvRzKGiism5FPaAPFZh9QoK33mG6EOnyVtooGlXdNHv9/eHlDWuwAm1P VoWxCkzMrBRdsZ9Fc1nc0+Wd2nY7WFYQgtnM018bC2W7uiVm5Moep0elfNyDv4q8/RMB CwIYmd8isw7ArvA8q2Ws/Jp2clxrA15MeJ/3QMmRq/veJa5+zkTxnYbsdwYbkCzyr+M+ Wjv3phC5xZJP3BruuNCUd/1PMTuVFererPieBefLBfy4pV61D2aJp4nzL97TJI8Gn6Ry QRAQ== X-Forwarded-Encrypted: i=1; AHgh+RqatFkUgWg8OA13U0OpARv0xXx7lNuznbAgKI+0Z6xof5AlSoFZMy3bjl6p8tca8D491Urr8+I+z1bUkkE=@vger.kernel.org X-Gm-Message-State: AOJu0YxNfCPNOs09R+p2Rh4KLwFcn6X/tXn2ZlqkR8G+YievgVvTghdX 5N5jtATRyzYI/SYfcCs45Z7sxfG/wgifB2vF9lOfx1hH2UjinxVEUUP7dLxAYJ4C0Q== X-Gm-Gg: AfdE7cnY7gu26gjXbvIuSBUt1yqrKvP+qP1+7/pDLDTWiVbjzrYUGse1z32QCcjqb+q wMg5+RtIk0o0XVi5F8wv8A2rn8Lv/MvtpNuCIfopDrtPsgeIKgxL6zvMiHPJSLzKS2tLMrV9Ovv PUDkb85Y2PWU4oIIbe8IPWoXWMi6S1uAd+D74Peei1S8l//OuP4vQLy/4F0KfIC54H9KVDSkrxp +SQCerMtoGEGSs08qCfphiKuGPYvcYjBiOwpcVXZm2R6JTSJv4BDoF4K7yZVcWAQqEylIirfwMJ Bw31PyNgtLfP9kaQuEBROXkbhEEtZcfihuqB07NzZZENmMdD4FWMoUpcFNcWostjB+PmKn7U+IA WRpHHaetSJoajTytohLM7WqACPMqwHz8bi78ObM/zHmh2u1u5SwNvLFijgimV92QS+FL5lSObPo aFWMfdStBl3XfwnU3/LGlVqXxtECp0MooA1Vw9Go5yM47Fj1+lWc5UDA1GZw== X-Received: by 2002:a17:903:22c5:b0:2ca:be81:b469 with SMTP id d9443c01a7336-2ccff679a46mr339855ad.0.1783530325931; Wed, 08 Jul 2026 10:05:25 -0700 (PDT) Received: from google.com (10.129.124.34.bc.googleusercontent.com. [34.124.129.10]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-2ccc9d5bdddsm30623695ad.77.2026.07.08.10.05.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jul 2026 10:05:25 -0700 (PDT) Date: Wed, 8 Jul 2026 17:05:20 +0000 From: Pranjal Shrivastava To: Samiullah Khawaja Cc: Pratyush Yadav , Mike Rapoport , Pasha Tatashin , Alexander Graf , David Matlack , kexec@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [RFC PATCH 0/4] kho: Support preserving unsplit high-order pages Message-ID: References: <20260703020832.1731864-1-praan@google.com> <2vxz7bn5mv0n.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: On Wed, Jul 08, 2026 at 04:36:46PM +0000, Samiullah Khawaja wrote: > On Wed, Jul 08, 2026 at 04:11:04PM +0200, Pratyush Yadav wrote: > > On Fri, Jul 03 2026, Pranjal Shrivastava wrote: > > > > [snip] > > > > > > 3. kho_restore_page() applies the correct refcount pattern based on the > > > preserved metadata. > > > > Why do you need to save the type of pages in KHO metadata? For example, > > for pages or folios, we don't store any type information and leave it to > > the caller choose the right API. So reserve-mem and kho vmalloc need > > pages, they can call kho_{preserve,restore}_pages(), and memfd needs > > folios so it can call kho_{preserve,restore}_folio(). The radix tree > > itself does not hold the information. The caller knows what its memory > > is supposed to be so it calls the right restore API. > > > > So why can't we add a kho_{preserve,restore}_page_multi() (pick a better > > name; we can argue about the naming later)? Then your driver knows it is > > restoring DMA buffers so it can call kho_restore_page_multi(), and KHO > > takes care of initializing the pages with the right refcounts. > > > > You won't have to muck about with the ABI in that case. > > +1 > > I think this makes sense. The mm already relies on the allocator to > track the type of pages it has and expectes it to use free_pages or > put_page() or free_page(), so it is natural for KHO to rely on the > caller to call the right restore API. > > Lets add kho_preserve/restore_page_contig|_order|_nonsplit and the dma > preservation can use the appropriate one during restore. Ack. I like kho_restore_contig, I don't think we'll need a preserve for this though? Preserve doesn't seem to be preserving refcounts, I guess we could rely on kho_preserve_pages and the caller can use kho_restore_pages_contig() to set refcount correctly for unsplit pages? Thanks Praan