[RFC PATCH 0/4] kho: Support preserving unsplit high-order pages

[Pratyush Yadav]

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