On Tue, Mar 25, 2025 at 12:19 PM Mike Rapoport <rppt@xxxxxxxxxx> wrote: > > On Mon, Mar 24, 2025 at 11:40:43AM -0700, Frank van der Linden wrote: [...] > > Thanks for the work on this. > > > > Obviously it needs to happen while memblock is still active - but why > > as close as possible to buddy initialization? > > One reason is to have all memblock allocations done to autoscale the > scratch area. Another reason is to keep memblock structures small as long > as possible as memblock_reserve()ing the preserved memory would quite > inflate them. > > And it's overall simpler if memblock only allocates from scratch rather > than doing some of early allocations from scratch and some elsewhere and > still making sure they avoid the preserved ranges. Ah, thanks, I see the argument for the scratch area sizing. > > > Ordering is always a sticky issue when it comes to doing things during > > boot, of course. In this case, I can see scenarios where code that > > runs a little earlier may want to use some preserved memory. The > > Can you elaborate about such scenarios? There has, for example, been some talk about making hugetlbfs persistent. You could have hugetlb_cma active. The hugetlb CMA areas are set up quite early, quite some time before KHO restores memory. So that would have to be changed somehow if the location of the KHO init call would remain as close as possible to buddy init as possible. I suspect there may be other uses. Although I suppose you could just look up the addresses and then reserve them yourself, you would just need the KHO FDT to be initialized. And you'd need to avoid the KHO bitmap deserialize trying to redo the ranges you've already done. > > > current requirement in the patch set seems to be "after sparse/page > > init", but I'm not sure why it needs to be as close as possibly to > > buddy init. > > Why would you say that sparse/page init would be a requirement here? At least in its current form, the KHO code expects vmemmap to be initialized, as it does its restore base on page structures, as deserialize_bitmap expects them. I think the use of the page->private field was discussed in a separate thread, I think. If that is done differently, it wouldn't rely on vmemmap being initialized. A few more things I've noticed (not sure if these were discussed before): * Should KHO depend on CONFIG_DEFERRED_STRUCT_PAGE_INIT? Essentially, marking memblock ranges as NOINIT doesn't work without DEFERRED_STRUCT_PAGE_INIT. Although, if the page->private use disappears, this wouldn't be an issue anymore. * As a future extension, it could be nice to store vmemmap init information in the KHO FDT. Then you can use that to init ranges in an optimized way (HVO hugetlb or DAX-style persisted ranges) straight away. - Frank > > - Frank > > -- > Sincerely yours, > Mike.
