> > > I think it should be the other way around, KHO should depend on > > > !DEFERRED_STRUCT_PAGE_INIT. > > > > Agreed, and this is what I first tried, but that does not work, there > > is some circular dependency breaking the build. If you feel > > adventurous you can try that :-) > > Hmm, weird, worked for me :/
I am super confused, it did not work for me over weekend, and now it is working. Even `make menuconfig` would not work. Anyways, I will put it in the appropriate place. > > > > > We will need to teah KHO to work with deferred struct page init. I > > > > suspect, we could init preserved struct pages and then skip over them > > > > during deferred init. > > > > > > We could, but with that would mean we'll run this before SMP and it's not > > > desirable. Also, init_deferred_page() for a random page requires > > > > We already run KHO init before smp_init: > > start_kernel() -> mm_core_init() -> kho_memory_init() -> > > kho_restore_folio() -> struct pages must be already initialized here! > > > > While deferred struct pages are initialized: > > start_kernel() -> rest_init() -> kernel_init() -> > > kernel_init_freeable() -> page_alloc_init_late() -> > > deferred_init_memmap() > > > > If the number of preserved pages that is needed during early boot is > > relatively small, that it should not be an issue to pre-initialize > > struct pages for them before deferred struct pages are initialized. We > > already pre-initialize some "struct pages" that are needed during > > early boot before the reset are initialized, see deferred_grow_zone() > > deferred_grow_zone() takes a chunk in the beginning of uninitialized range, > with kho we are talking about some random pages. If we preinit them early, > deferred_init_memmap() will overwrite them. Yes, this is why I am saying that we would need to skip the KHO initialized "struct pages" somehow during deferred initialization. If we create an ordered by PFN list of early-initialized KHO struct pages, skipping during deferred initialization could be done efficiently. > Anyway, I'm going to look into it, hopefully I'll have something Really > Soon (tm). CC: Michal Clapinski, who was also planning to look into this problem. Pasha
