Re: [PATCH] kho: add support for deferred struct page init

[Pratyush Yadav <pratyush@kernel.org>]

On Tue, Dec 16 2025, Pasha Tatashin wrote:

> On Tue, Dec 16, 2025 at 10:36 AM Pasha Tatashin
> <pasha.tatashin@soleen.com> wrote:
>>
>> On Tue, Dec 16, 2025 at 10:19 AM Mike Rapoport <rppt@kernel.org> wrote:
>> >
>> > On Tue, Dec 16, 2025 at 10:05:27AM -0500, Pasha Tatashin wrote:
>> > > > > +static struct page *__init kho_get_preserved_page(phys_addr_t phys,
>> > > > > +                                               unsigned int order)
>> > > > > +{
>> > > > > +     unsigned long pfn = PHYS_PFN(phys);
>> > > > > +     int nid = early_pfn_to_nid(pfn);
>> > > > > +
>> > > > > +     for (int i = 0; i < (1 << order); i++)
>> > > > > +             init_deferred_page(pfn + i, nid);
>> > > >
>> > > > This will skip pages below node->first_deferred_pfn, we need to use
>> > > > __init_page_from_nid() here.
>> > >
>> > > Mike, but those struct pages should be initialized early anyway. If
>> > > they are not yet initialized we have a problem, as they are going to
>> > > be re-initialized later.
>> >
>> > Can say I understand your point. Which pages should be initialized earlt?
>>
>> All pages below node->first_deferred_pfn.
>>
>> > And which pages will be reinitialized?
>>
>> kho_memory_init() is called after free_area_init() (which calls
>> memmap_init_range to initialize low memory struct pages). So, if we
>> use __init_page_from_nid() as suggested, we would be blindly running
>> __init_single_page() again on those low-memory pages that
>> memmap_init_range() already set up. This would cause double
>> initialization and corruptions due to losing the order information.
>>
>> > > > > +
>> > > > > +     return pfn_to_page(pfn);
>> > > > > +}
>> > > > > +
>> > > > >  static void __init deserialize_bitmap(unsigned int order,
>> > > > >                                     struct khoser_mem_bitmap_ptr *elm)
>> > > > >  {
>> > > > > @@ -449,7 +466,7 @@ static void __init deserialize_bitmap(unsigned int order,
>> > > > >               int sz = 1 << (order + PAGE_SHIFT);
>> > > > >               phys_addr_t phys =
>> > > > >                       elm->phys_start + (bit << (order + PAGE_SHIFT));
>> > > > > -             struct page *page = phys_to_page(phys);
>> > > > > +             struct page *page = kho_get_preserved_page(phys, order);
>> > > >
>> > > > I think it's better to initialize deferred struct pages later in
>> > > > kho_restore_page. deserialize_bitmap() runs before SMP and it already does
>> > >
>> > > The KHO memory should still be accessible early in boot, right?
>> >
>> > The memory is accessible. And we anyway should not use struct page for
>> > preserved memory before kho_restore_{folio,pages}.
>>
>> This makes sense, what happens if someone calls kho_restore_folio()
>> before deferred pages are initialized?
>
> I looked at your repo. I think what you're proposing makes sense, and
> indeed it will provide a performance boost if some of the folios are
> restored in parallel. Just kho_init_deferred_pages() should be using
> init_deferred_page() to avoid re-initializing the lower memory pages.
> Also, I am still wondering how it will work with HVO, but I need to
> take a look at Pratyuh's series for that.

The HVO optimization happens when the file is retrieved, after all the
folios are restored. So that is long after deferred page init. For my
series both approaches should work.

-- 
Regards,
Pratyush Yadav