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 75C90494A0C for ; Wed, 8 Jul 2026 14:34:11 +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=1783521252; cv=none; b=j3jb5fF/x4+inui/UiEo8tPyFY61fCiZMKiMXVGvU3yoBQneZXQ38TD3y8ebXAypl0/CNmTrns4REnw+podlHsdQvEp60LpjKWipEAqbdNQrFwy6I2rajdO/DmneQbOLpQRSKpzcWi78H71KTsnuzpSdl49wJqmD8EvJRTEbqMY= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783521252; c=relaxed/simple; bh=yuBLfoR14po1B4YwuyHzghfv/QZ5bZtNKVUEWG+6ULc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=MlCB+gBNTcIIkkopDv1g9NMVqrDR/y8tkFNYHMqGIv/GTkVkUHzSdAGiN+ZqsaVj34zTfZtdbsekhjHG0akEvtPzNTi8oZ5YtD6YZj2szWPRxPi/ezj04PsXw4z2lP907NDBOq8sRanJXQAyvdxKFUm67E341sSIZ26/ZVuBlhQ= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=gkp8WN81; 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="gkp8WN81" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 977651F00A3A; Wed, 8 Jul 2026 14:34:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1783521251; bh=yMl/Hl9vchj200XFGcGCOCkDW3TMDHU36nBeESh9U+g=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=gkp8WN81Xw1+3ZEkuWvUYxFshXJZ/yQOPS7JoVjHAG33Ow3qX6AMrvVMPVydpxbJr NjWhiPqXSxGGTD6P1tK49i1Iu88eYDUyp5560l8rg0In5aPnqZUp3veBvqCFfhYPw5 jORC0MmWPIsTYbmOwLQu7NQ9zwVmIZ52rxC04wkaDcUJ8nj1eHp6t6hpmlwQq3h3vI ksb525Q3DGV/pcBOebrChZQfScER8OFD89JWU5slohAEvMjcJ+dHGk5VKJdHkrvCFu PCcu51S1BU+7AI8LN7lpTDnbUWWzeTz4Wsg0ynFQp7YbluiF/mC2mwovOdkygZ32n5 SjiWo06DMVvVg== From: Pratyush Yadav To: Mike Rapoport Cc: Pranjal Shrivastava , Pasha Tatashin , Pratyush Yadav , Alexander Graf , Samiullah Khawaja , 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 In-Reply-To: <178341290876.3292146.16538284698967245356.b4-review@b4> (Mike Rapoport's message of "Tue, 07 Jul 2026 11:28:28 +0300") References: <20260703020832.1731864-1-praan@google.com> <178341290876.3292146.16538284698967245356.b4-review@b4> Date: Wed, 08 Jul 2026 16:34:08 +0200 Message-ID: <2vxz33xtmty7.fsf@kernel.org> User-Agent: Gnus/5.13 (Gnus v5.13) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain On Tue, Jul 07 2026, Mike Rapoport wrote: >> 2. The type bit is preserved in the high bits of the KHO radix tree key >> (Bit 63) and stashed in page->private metadata during boot. > > This brings a broader question - what is the best way to deal with page > metadata. This particular case requires only a single bit and luckily we > have a few spare high bits in the radix tree key. But what if going > forward we'll need more than a few bits? Do we need a parallel data > structure for the page metadata? Or something in kho_radix_leaf in > addition to the bitmap? FWIW, I am not convinced we need the extra bit of metadata _in this case_ [0]. But in general, I think the answer depends on how many pages need that metadata. Storing it in the key has a side effect because it increases the memory usage. Since the keys will be more spread apart due to the metadata bits, it will result in more radix table pages being allocated. If we need the metadata for each preservation, I'd guess we should just change the leaf nodes to have more bits per key instead of just one. If the metadata is fairly rare, maybe we just do a parallel data structure. Although parallel data structures do run the risk of going out of sync. So I guess it depends on the use case, as always... [0] https://lore.kernel.org/kexec/2vxz7bn5mv0n.fsf@kernel.org/ > > I'm not saying that a generic solution for page metadata must be a part > of this series, but we definitely need to consider and better sooner > than later. -- Regards, Pratyush Yadav