> I didn't mean the exact flags value, but the ability to have > per-folio flags. The exact bits and their meaning would of course > need to be part of the ABI. Shmem uses the dirty and uptodate flags > to track some state on the folios, and the flags can affect it's > behavior (lazily zeroing out falloc-ed pages for example). I am > assuming other FD types or drivers might also want to store > per-folio information. Having KHO core provide this facility can > avoid duplicating the logic in each subsystem. For something simple like shmem I'd probably just suggest a side car bitmap array or something? The trouble with trying to feed flags through the xarray thing is that the memory holding that pfn data across the kexec is not itself preserved memory so it is all blown away once the allocator starts. Any data that needs to be preserved further has to be copied into the frozen struct page, which is pretty limiting in terms of what you could preserve. A few bits could maybe work out but not alot of data. > For FDBox, it is certainly possible. In the current patch version, > deserialization happens on boot so it can't be done, but in later > versions I want to give userspace control on when to deserialize. So > whichever context triggers that gets charged. Yeah, I think allowing userspace to sequence the deserialize is important. Jason
