On Fri, Apr 04, 2025 at 12:54:25PM +0300, Mike Rapoport wrote: > > IMHO it should not call kho_preserve_phys() at all. > > Do you mean that for preserving large physical ranges we need something > entirely different?
If they don't use the buddy allocator, then yes? > Then we don't need the bitmaps at this point, as we don't have any users > for kho_preserve_folio() and we should not worry ourself with orders and > restoration of high order folios until then ;-) Arguably yes :\ Maybe change the reserved regions code to put the region list in a folio and preserve the folio instead of using FDT as a "demo" for the functionality. > The xarrays + bitmaps do have the limitation that we cannot store any > information about the folio except its order and if we are anyway need > something else to preserve physical ranges, I suggest starting with > preserving ranges and then adding optimizations for the folio case. Why? What is the use case for physical ranges that isn't handled entirely by reserved_mem_add()? We know what the future use case is for the folio preservation, all the drivers and the iommu are going to rely on this. > Here's something that implements preservation of ranges (compile tested > only) and adding folios with their orders and maybe other information would > be quite easy. But folios and their orders is the *whole point*, again I don't see any use case for preserving ranges, beyond it being a way to optimize the memblock reserve path. But that path should be fixed up to just use the bitmap directly.. Jason
