On Wed, Sep 03, 2025 at 06:38:00PM +0300, Mike Rapoport wrote: > > Don't call kho_preserve_phy if you already have a page! > > Ok, I'll add kho_preserve_page() ;-P.
Cast it to a folio :P > Now seriously, by no means this is a folio, It really is. The entire bitmap thing is about preserving folios/page which are basically the same thing ATM. folio is the prefered type for what used to be compound pages. As Matthew moves ahead it will effectively become preserving memdescs. This may even start to happen this year.. Every memdesc has a type, so when ever the physical pages are restored KHO will need to recreate the struct page and page->memdesc with the correct values, including the memdesc type code and any memdesc allocation that Matthew plans. Meaning everything should be struct page or folio based at this API level, and restore functions should be logically paired with the allocation functions that created the memory in the first place. vmalloc() is calling alloc_pages_bulk_node_noprof() to allocate the memory, so the restore of that memory should also have a 'kho restore page' type of name that clearly refers back to the allocator it pairs with. In the more general case this should be setting the cgroup and charging it as well. > How do you suggest to preserve memblock? Does the memory have a struct page? Then it should be a preserved folio list so you get back struct pages in the right state for what memblock is doing. Someday that will turn into some specific memdesc type and so on. If it doesn't have a struct page then it shouldn't be in the bitmaps at all. Jason
