Re: [RFC v1 0/4] Make KHO Stateless

[Pratyush Yadav <pratyush@kernel.org>]

On Thu, Sep 25 2025, Mike Rapoport wrote:

> Hi Jason,
>
> On Tue, Sep 16, 2025 at 07:50:15PM -0700, Jason Miu wrote:
>> This series transitions KHO from an xarray-based metadata tracking
>> system with serialization to using page table like data structures
>> that can be passed directly to the next kernel.
>> 
>> The key motivations for this change are to:
>> - Eliminate the need for data serialization before kexec.
>> - Remove the former KHO state machine by deprecating the finalize
>>   and abort states.
>> - Pass preservation metadata more directly to the next kernel via the FDT.
>
> If we pass the preservation metadata directly between the kernels, it means
> that any change to that data structure will break compatibility between the
> new and old kernels. With serialization this is less severe because a more
> recent kernel can relatively easy have backward compatible deserialization.
>
> I'm all for removing KHO state machine, but that does not necessarily mean
> we must remove the serialization of memory persistence metadata?

I think the tables should be treated as the final serialized data
structure, and should get all the same properties that other KHO
serialization formats have like stable binary format, versioning, etc.

It just so happens that the table format lends itself very well to being
serialized on-the-go. When a page is marked as preserved during normal
operation, it is very simple to just allocate all the intermediate
levels and mark the page as reserved. There is no further processing
needed to "serialize" it -- like we need to do with the bitmaps today.

So I don't really see why we should introduce an intermediate processing
step when it is easy to just directly build the serialized data
structure during normal operation.

>
> For example, we can do the serialization at kernel_kexec() time and if we
> want to avoid memory allocations there we might preallocate pages for
> khoser_mem_chunk's as amount of bitmaps grow.
>
> It also would be interesting to see how much time is saved if we remove the
> serialization.

-- 
Regards,
Pratyush Yadav