From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f181.google.com (mail-pl1-f181.google.com [209.85.214.181]) (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 06C913B14B3 for ; Wed, 8 Jul 2026 16:36:50 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.181 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783528612; cv=none; b=T7jUA+plTC9QWtmCHy4h3DL9hra8IFYXItIIn2nD/95sKHs7nSiyOyyGPaGhloaxFDQM8GVi6dD7WjggEjo7s9+Jy0yR6PVK4TLUDMCCRiBGGhptF2NN7ncvTBvR4muCniPx6LR4GWLjaRgHGBVBu1Y1NxFSKuw2+2fxuKn9SgQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783528612; c=relaxed/simple; bh=uLvpoqcB3p+Z2qZRX7ok5RaU0VfVMSJdEy3hukrQ9Xo=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=DWswDy2yFRxtEnbzliAb04GHt/GZ71uSCq/RHvS4CEGnkvge8a2y5tMWqcCsFd8sOcGwWJrv7ozbogWVKVz0JORU8Lxf6g1yg8Z3OUGSiG5fQcmThr8Me6y4u6E8jTKEUSRIJeIiJ67GEl7haNcDMvmtjTpOvCZl/AeuP6OVBSg= 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=Mo1HZbPw; arc=none smtp.client-ip=209.85.214.181 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="Mo1HZbPw" Received: by mail-pl1-f181.google.com with SMTP id d9443c01a7336-2ccdf36f63dso156865ad.0 for ; Wed, 08 Jul 2026 09:36:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20251104; t=1783528610; x=1784133410; 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=jru2Xn1d/tBHCWGdcqrYsKFvTPIWXgg78WJpvLW47rw=; b=Mo1HZbPwotSsfGmRXfG8TCipkAn4FbaLBl6lwVvSU48DECLuuPTB9P83eMy5hpXkZ3 FNKpz4ATUpv22sqcBiBwHzZ6z+Pez/Ds9Lp8kCAWhOY7MElWW480TeKVjQdY8xM7VxA1 YF/Mt/WwQj5BjWZetyHkuU1MCJNRBYt4Vvm8rvbt0WMEhiOPdFk00TdoZs3C1Z1rSGP6 2ccENyZK/b+e0cdgzRqMFbuP+ENcCJsuyBvEq34VWh/iDSqfq1V0TB1L6sT5IjvbND+i ZhAgW7CacJAxLE/3+zqcqOwPAnzQZkzeykrqzixOtrzNPHRXUQMVy07HmQhyviGj9CBw Py8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1783528610; x=1784133410; 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=jru2Xn1d/tBHCWGdcqrYsKFvTPIWXgg78WJpvLW47rw=; b=F68ocb+vmBf81psKZsxoPnZJkWeLLnLeX4miG84cSBrJLvYOJ3vZFK+rr024jMDgbk +9kt9GY6IPd09BDWYVLJprPmdE/9jrMzf3IMgsLTcptjC0sG4YYkCCxKeC1jcnymEJ5O QGkQ9bar8pt3AvultMUD26rd2ZUTAAtxTX3Pu9Br99kEot+PzMpi7g9CyReltN+l2koB 83CkKYyrdxSaQQnZn5CzxrAcg8cnoDXpRuM/jjecm4NXcXI899/+tJX2Y9Fddy00jNiS 2hOWVh29MKTXYwzw95ecikxgZwZH0GAghnJd7q0lrKUxFiM5fG87s01xTYWig1lFOotW qmfA== X-Forwarded-Encrypted: i=1; AHgh+RolXPuBLXDeM3WNJUr4KOqOdiR2w82ncHZjgKikGgr5/fShiEGCUrG6EMSYs9lStco2Z4LfrLx9tgoMtMQ=@vger.kernel.org X-Gm-Message-State: AOJu0YxsW0qQLU2sGpeE3NiKkYyrDS39F9RkLTx1pCC4eCc4Y6to12Th uscmZzEywywS3paruWiEC+RBDJz0f4aFZpO15PadgRv3pjuOOBLO51LIXoEKXtRlcg== X-Gm-Gg: AfdE7clg+whwFzWDiK5bfWwuC+Lg+lEtUoQ3cl6MtMPpiqIO9X35Ntip3QWkbgSWTkH t6aFXy8ShEKbGZQG+SA+8NF0IK61PoL+U+zf54Cbs/rKXSnZRt3L93DZ5Hh//WxgDL233QyjBQ4 no4POZbw/s2LR2xoKVxoPXAVjOmJDkcPWWYY0soJkXPCzaheNgje17+KYcg0/DqfrLBxurbeFYy nXVTwayVbDQUFE99w6JgxA3xfwocr8gvG2UdXncaeye95vIqK61cLd77xjUu/QYrd8SKAvSe0aT eblttSmea/W309drhNARgAWgoIsadXh9DTXtY3Zb7+CPFMOvYbZICbD92Wa4QQYfDCDAIEYj+zc DqVeS186LkR061aItKVR/8uqVbF7hCGLj6mWzT50dJQTyrBdohJKgC8Ot4P6rtiNzpPMYGKOV+b MkJNAa/Xsrl02cs8448Eoyqu54m/XViaUDnEurm7iHvmY7icVvgp+eNlMzglTAUZ8G5rKqbzeeh bBnU5y71KKWbfH0390YWQ== X-Received: by 2002:a17:902:d4cd:b0:2bf:3579:cdaa with SMTP id d9443c01a7336-2ccff76d125mr137455ad.10.1783528609731; Wed, 08 Jul 2026 09:36:49 -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-84854bf8c9asm66186b3a.41.2026.07.08.09.36.48 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Jul 2026 09:36:49 -0700 (PDT) Date: Wed, 8 Jul 2026 16:36:46 +0000 From: Samiullah Khawaja To: Pratyush Yadav Cc: Pranjal Shrivastava , 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: <2vxz7bn5mv0n.fsf@kernel.org> 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. > >> >> 4. A new helper, kho_split_preserved_pages(), is provided for subsystems >> that may need to split memory after it has already been preserved. > >Umm, that sounds scary... Why do you need to do that? What's the use >case? Why is the driver reconfiguring its memory after preservation? I >assume these are DMA buffers, so why do they suddenly look different? > >And in either case, why does KHO need to do the split? Why can't the >driver unpreserve old preservation, then split the pages, and then >preserve the new ones? > >> >> Considerations >> ============== >> >> 1. A primary goal of this approach is to prevent driver/subsystem code >> from peeking into MM internals. Drivers should not need to understand >> the distinction between head/tail pages or compound metadata. The KHO >> core handles this internally. >> >> 2. To handle rare cases where a caller might wish to split a high-order >> block after preservation, we provide kho_split_preserved_pages(). >> >> 3. The callers must ensure that the split_page() doesn't race with >> kho_preserve_pages for consistency. >> >> 4. Folios are always implicitly considered of the CONTIG type >> >> Thanks, >> Praan >> >> [1] https://lore.kernel.org/all/20260505002737.2213734-1-skhawaja@google.com/ >> [2] https://elixir.bootlin.com/linux/v7.1.1/source/mm/page_alloc.c#L1370 >> [3] https://elixir.bootlin.com/linux/v7.1.1/source/mm/page_alloc.c#L1027 >> [4] https://elixir.bootlin.com/linux/v7.1.1/source/mm/page_alloc.c#L1034 >> >> Pranjal Shrivastava (4): >> kho: Introduce infrastructure to track preserved page types >> kho: Detect preserved page types >> kho: Implement page-aware refcount restoration >> kho: Introduce kho_split_preserved_pages() helper >> >> include/linux/kexec_handover.h | 7 ++ >> include/linux/kho_radix_tree.h | 17 +++- >> kernel/liveupdate/kexec_handover.c | 144 +++++++++++++++++++++-------- >> 3 files changed, 124 insertions(+), 44 deletions(-) >> >> >> base-commit: 87320be9f0d24fce67631b7eef919f0b79c3e45c > >-- >Regards, >Pratyush Yadav Sami