Message-ID: <CA+CK2bBoMfJuUCV6sL80kwzYPnENnt7fDk2jRMPV0iPn1jCJdw@mail.gmail.com>
Date: Wed, 11 Jun 2025 09:14:55 -0400
From: Pasha Tatashin <pasha.tatashin@...een.com>
To: Pratyush Yadav <pratyush@...nel.org>
Cc: Mike Rapoport <rppt@...nel.org>, Alexander Graf <graf@...zon.com>, 
	Changyuan Lyu <changyuanl@...gle.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	Baoquan He <bhe@...hat.com>, kexec@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	linux-mm@...ck.org, Michal Clapinski <mclapinski@...gle.com>
Subject: Re: [PATCH] kho: initialize tail pages for higher order folios properly

On Wed, Jun 11, 2025 at 9:06 AM Pratyush Yadav <pratyush@...nel.org> wrote:
>
> On Tue, Jun 10 2025, Pasha Tatashin wrote:
>
> >> > > 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 :/
>
> Worked for me as well.
>
> >
> > 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.
>
> Or keep things simple and don't use any KHO struct pages during early
> init. You can access the page itself, just don't use its struct page.
>
> Currently the only user of kho_restore_folio() during init is
> kho_memory_init(). The FDT is accessed by doing
> phys_to_virt(kho_in.fdt_phys) anyway, so there is really no need for
> restoring the folio so early. It can be done later, for example when LUO
> does the finish event, to clean up and free the folio.

Good suggestion, however, KHO does not have any sophisticated users
that we are going to be adding as part of the live update work in the
future: IR, KVM, early VCPU threads, and so on. So, while today, this
might work, in the future, I am not sure if we should expect struct
pages are not accessed until after deferred initialization or simply
fix it once and for all.

Pasha

>
> --
> Regards,
> Pratyush Yadav

Powered by blists - more mailing lists