From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) (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 0E5612E7631 for ; Wed, 8 Jul 2026 17:14:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.174 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783530886; cv=none; b=V6dTLi2fpZ7zzKPQJUk0lvZsrTyKFjcTNQPJyz24F7iDLD9BhRhX5eTxLZiSOxX++xeZubTagmDZWaHOMn0z9JOs7FXeo9VJWM86BM/XFRhg8h/ifi85FZmkY1UrBjaXs08oRJwdB0uMjiiWTE/P2G3XJsrRowiWvdNqw57Ss9Y= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783530886; c=relaxed/simple; bh=FaHBaJop+RRqpI4Fm4o6RivNZ51QW/8lPKO82k2x0P4=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mE6VdHN2FUB7e5/8k1CbLRYUDzYahDd6uqbH9Ijh3N0g4jFRZ5vcFF6sMShHBXh04BGuJFWiixXI+0nAcLJjVbOi77mqzYMgTaCtGPuR9BNA3T6t4Mdj+kcKE+si2FniwEAITHwF9Kb5DLWj5uRiza3Ss3M7J1ocntn96Xly61c= 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=DbedBwmy; arc=none smtp.client-ip=209.85.214.174 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="DbedBwmy" Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-2ccdf36f63dso5125ad.0 for ; Wed, 08 Jul 2026 10:14:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1783530884; x=1784135684; 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=I81HX2GmopBIWHT1e1Dpw4r52DG7HH+WAATQwe2SKiI=; b=DbedBwmyyqkvMoDTst1obAdjCNQqzkqpSvkr1EY7BQEMltEnVztchEa5+xjf0hrmN6 2LHVN8FNtHapIU5NaxfLSpbWvp3U8wMJ57PJGkVaEpH/OCkXjNG0wdfCFiV1XOzvOPN7 oC6rWs2llPLKEWDqays+YBKtVljzLOrnQuZaU3vAhfgVdhLwFxErND71h0nhhXuYwyJs 7zw2/cIPXdGPwE0UCG+cqDjAk9kVVnVKZMbNGa+LzuhMi0gRCcAgvwI4+RDzpjhMqgL9 /8BFhPwDSgrLepix3i06WmwAKA3U0gSnXj1cNerc7RiqG2UQ4wpkJsvZulFY+/a3qOpe 9AYQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783530884; x=1784135684; 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=I81HX2GmopBIWHT1e1Dpw4r52DG7HH+WAATQwe2SKiI=; b=FVQbfJrcDRQ9kd95eF9E/M9pz/CWmG3PpS4kFvPjriNTDNdHlf/9o9YB9LeeM1k27D oMca+xY0QJLRlTB4qe5pXz1tV4T06P0GFwiJ9bSSMLIJuVqG7f0U62kaCY04kx+3Tvpp HhFpyG4Ft8xVZmornXcorbCtq8+f3qck1z/jZ6YPPDubk0AADWBSSUUstMcKHboCYVAT CMBWa+3l7EU3JHuVAkeOss/KfJx+3+CHR6qRqAqGgPP4fs4RKjV4xwFziVTa0Ez68G08 mFzg4oEHhv06CzedeX/ImlIctxf2oERGUTWAH65xgtvxhOIXX2ptfyC59YhT14gpxmJq cL9Q== X-Forwarded-Encrypted: i=1; AHgh+RoECaMhD+wygqAo3OMq3TQQDOHoWZmYfCu0MZRA6c/iExwtXpcm5/jxq9TxrGLJM3XUjCULvCTs2BcfVyk=@vger.kernel.org X-Gm-Message-State: AOJu0YzrmJbqNQtsNfX+X7sCCY5Wwrc241+lGWnGb/hYxIgJVco9H8UF rGBHLsOYvFod1kLjZ4Ub+rjYFfXXwIoxYBAoKurfkLYwiAdwzP8Y6GaVH3M9+aTibg== X-Gm-Gg: AfdE7ckFdMrhzmJlRmtkLKAIoWES/fdNX8CHdVZJTpsAIkyzDQjF2BqrTanKLj4yiU1 j+eh36ZP1wY1n03JUVjzoJoSR/4YBLuSLoPH4DcWM0JAFLJs96pH1PshlfniW0xhaj7bXoJf33Y pr4jWD/rDMINR61wb54cbNuBlpvYg0V/VXdKGLZ/WAv3ADLQTuMil0bSqExQ9NAP1AdOD8bl6iB yqPp5YIYNxQo3FY4iw+6s6/oT7OFB2rTastFF1/OpJFclcE+OPKcC3A14yzW4oK1H32QGPMwBi0 eaL11WFjQzjXAIpPPmJMmc9R/3c1UdijJRPiUWGmcugNxZWZvTbtNI85IGaTF+6gI45ZCjasJp+ zrqOh1oQiSC1vPWleIJEDsezsWjJgbMpK7ffm3B751BSpYumtF11dTEF6shfzjBP6B2tBJeatFl wJIu00gotw3gaJNuK7O4+dJyrOcqzgwA1qTXwv4Kjj5IyA5Bi1vqNYbGuermwpJn+nzJgV+vdD/ uFMjaLs0yo= X-Received: by 2002:a17:902:cec1:b0:2b0:b0c9:96e2 with SMTP id d9443c01a7336-2ccff91bcfamr243315ad.21.1783530883940; Wed, 08 Jul 2026 10:14:43 -0700 (PDT) Received: from google.com (168.136.83.34.bc.googleusercontent.com. [34.83.136.168]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-847f6b6162esm7529105b3a.11.2026.07.08.10.14.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jul 2026 10:14:43 -0700 (PDT) Date: Wed, 8 Jul 2026 17:14:40 +0000 From: Samiullah Khawaja To: Pranjal Shrivastava 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; format=flowed Content-Disposition: inline In-Reply-To: On Wed, Jul 08, 2026 at 05:05:20PM +0000, Pranjal Shrivastava wrote: >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? I think for consistency we can add both, even if preserve doesn't do anything special internally. > >Thanks >Praan Sami