From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) (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 88DAC270540 for ; Wed, 8 Jul 2026 17:46:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783532811; cv=none; b=aE9ksAR4yo743qYYrzNtzz7wMBO5YBbjyd1wxSMBO14sQJnT4CT6HFqaGGjxHpf1CWSkOqUonoBcU8kG0s8ofyJql0FsIyTld3ouoUyHgScjuw5N2DIEj1S7GY7cp2cFp66fyaBHUXrb3BMIUKzcKSBU7H4wAok14l2CyIY8aak= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783532811; c=relaxed/simple; bh=YVLjW4K8jMEg+nXuj/4Jt3HMWoLXrj0TGtNJD2BjFyo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=EoVMoFA1hVUaslYuIcQZyt517X3rXPCp+gd9vIrNT+K+GoxaR8x/7Xnw9XwOWrEe90qYT5arT2S/fDil1mTg53QIeqS/Ntkr8CVasGcIYloF8jLOGz1G9puATlqngRkS7C7jYe/E7XnN8WXBqKg9dzB6V5ZjZM8dn53bNzE43B0= 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=MieVcgeL; arc=none smtp.client-ip=209.85.214.182 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="MieVcgeL" Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-2ccdf36f63dso10135ad.0 for ; Wed, 08 Jul 2026 10:46:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1783532810; x=1784137610; 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=T72id7RPi86+PG3iZJFHATNYzmFCFJW00jDywLiIkEk=; b=MieVcgeLHOWKj7QroQo1aK+A9qQ2s9u9VjkNHWjd4UtNRktURpv+1QzAy2e70eAx8Z kVW6Wm6LHm3JJHyJqdZsDoanVxQ13S0/86BpzRbwHm00j0nkG7s3S9V9lvOOU7F7jG1q 1ujTIVPBksqbIRsnUUa3Hs20SrSOSxbYsp4/AhXFd6MfnTWEpHXoW3S/goK5zRgLPmnV TUaQhoNFsOVUYPUbHyc0thMW92B7mttW7SNfXYOUaWDg0PGbUcPqmTAQ2aG/KapBOitP MK5Tn8FLa5QdWlKZ9gyk7T7J2TEi9+CAsHUVVrjCPTTelqgoclrTamnfVUkSicWxusbF 927Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783532810; x=1784137610; 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=T72id7RPi86+PG3iZJFHATNYzmFCFJW00jDywLiIkEk=; b=QgoPQ5PjgTkswfGHivhxMuzzXONaMLNMy5SJbwzXua2bwRytFjTNpymbvmp7nkI3vr jOA1CPGiFk68W1YUu0ZGPaA6Zp87co1Ylg65Ik5Oj6zufvuKmywh9RY+mqazqx2RQ0kR Mu14bgClSjJMFif+AK/RKIXqN8m7bli/rBgSl5niFqN7ylbrZzHQEMCxCHGf9UY7BYYI kCrYGuY3IBGoiuUfwSGMYNm8ZGKOrLiWh8DJ1IdFRWsGtL8RULCP/+gFS5quXdwvKPZZ +Ofvd8kILr2V+LlAEyMnKL7wApbp7JZZWWAGweZ/UOurUnncSlq5FmySutuzAw+oIy2A uXjQ== X-Forwarded-Encrypted: i=1; AHgh+RoiWDP5srEfGPLU+5SEctuT8HEPqwCOFSV7DlY7OLUYwzSMorCJ4kqC+6FRq0Bgv81q362Gvs2oFedS6ZI=@vger.kernel.org X-Gm-Message-State: AOJu0Yx1NzPGxZpxLxPvRXD6fLUyeE637j9bxTyNbPdj+WcyQB/eytB5 iJ0zj+WIAWdx8Nw90OcJHrds8dVd0quzf23H0WmfvrQeUxYbshZTqG11rjZMGyHpog== X-Gm-Gg: AfdE7cngosN+TCm6xF8edtCrsO+Yk+AIoVkF+tnJ+RQXMewtc0Fz+BWcVZBvB+JTXrL lEOtfyzuK2VE26obmYX24JMrqlQBsxOBM6C63c/xqndhnq60E0HeQgmuVea8boIvpTDSnC5TbNn DPNnFyXBMMsmdxGqoF5dJOVWmIHfdjOmMB8CwAMND3R1AnJ12B77QG1G8ArVgiV6Hi41A8qFVCu avdDNDRY7h6U5B+2iq5RN+S+GI9EGyrDWhrZ6p/z9ykUrMC+hGo2ILlWx+Xdltfx9Qr+4fxczPG 1Jhnwcpu61jGrDUX5HnzMFoLhaNkTk7vGTMO8HNoJC4ZrHs7jXEJeVnYmEsB29uOsThHQVQJIcw iVf5/N27dKWDJID40aDbqJ0hLMt2+doaw/Zgzlq1s7RtcaWDw425xZq1CC9RamX9oKzvHd9w3Wr Qb/WXF23LBpbji44HDiFin3JGjGMiuzDVlCLSLe4xq/FsDX0U= X-Received: by 2002:a17:903:32c7:b0:2c9:a222:47e0 with SMTP id d9443c01a7336-2ccff85d2fcmr469435ad.20.1783532809401; Wed, 08 Jul 2026 10:46:49 -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-2ccc9d1eea1sm31610665ad.46.2026.07.08.10.46.46 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jul 2026 10:46:48 -0700 (PDT) Date: Wed, 8 Jul 2026 17:46:43 +0000 From: Pranjal Shrivastava To: Pratyush Yadav , h@google.com Cc: Samiullah Khawaja , 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> <2vxzy0fll71f.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: <2vxzy0fll71f.fsf@kernel.org> On Wed, Jul 08, 2026 at 07:34:20PM +0200, Pratyush Yadav wrote: > On Wed, Jul 08 2026, 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 > > Dunno, everything is contiguous, folio, 0-order pages, higher order > pages. So not exactly the best name. > > Since you'd get these pages via alloc_pages, perhaps > kho_preserve_pages() works better for this kind of allocation, and for > the _current_ kho_preserve_pages(), we can rename it to > kho_preserve_split_pages()? It is a bit too wordy though, so that's a > downside. > I suppose this is to preserve unsplit higher order non-compound pages. kho_preserve_unsplit_pages() ? > Mike, you are better than me at naming things, so do you perhaps have > any better ideas? :-) > +1 would love everyone's help here :) > > 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? > > No, kho_preserve_pages() can split the preservations in unexpected ways. > While for a high order pages the current algorithm _shouldn't_ do it, it > is simpler to just add a new preservation function. > > Move things out into helpers if you want to avoid duplication, though at > first glance I don't think there should be much. Ack, I'll add another preserve helper. > > -- > Regards, > Pratyush Yadav Thanks, Praan