On Wed, Nov 12, 2025 at 07:46:23AM -0500, Pasha Tatashin wrote:

On Wed, Nov 12, 2025 at 5:21 AM Mike Rapoport [off-list ref] wrote:

quoted

On Tue, Nov 11, 2025 at 03:42:24PM -0500, Pasha Tatashin wrote:

quoted

On Tue, Nov 11, 2025 at 3:39 PM Pasha Tatashin
[off-list ref] wrote:

quoted

quoted

quoted

      kho_memory_init();

+     /* Live Update should follow right after KHO is initialized */
+     liveupdate_init();
+

Why do you think it should be immediately after kho_memory_init()?
Any reason this can't be called from start_kernel() or even later as an
early_initcall() or core_initall()?

Unfortunately, no, even here it is too late, and we might need to find
a way to move the kho_init/liveupdate_init earlier. We must be able to
preserve HugeTLB pages, and those are reserved earlier in boot.

Just to clarify: liveupdate_init() is needed to start using:
liveupdate_flb_incoming_* API, and FLB data is needed during HugeTLB
reservation.

Since flb is "file-lifecycle-bound", it implies *file*. Early memory
reservations in hugetlb are not bound to files, they end up in file objects
way later.

FLB global objects act similarly to subsystem-wide data, except their
data has a clear creation and destruction time tied to preserved
files. When the first file of a particular type is added to LUO, this
global data is created; when the last file of that type is removed
(unpreserved or finished), this global data is destroyed, this is why
its life is bound to file lifecycle. Crucially, this global data is
accessible at any time while LUO owns the associated files spanning
the early boot update boundary.

But there are no files at mm_core_init(). I'm really confused here.
 

quoted

So I think for now we can move liveupdate_init() later in boot and we will
solve the problem of hugetlb reservations when we add support for hugetlb.

HugeTLB reserves memory early in boot. If we already have preserved
HugeTLB pages via LUO/KHO, we must ensure they are counted against the
boot-time reservation. For example, if hugetlb_cma_reserve() needs to
reserve ten 1G pages, but LUO has already preserved seven, we only
need to reserve three new pages and the rest are going to be restored
with the files.

Since this count is contained in the FLB global object, that data
needs to be available during the early reservation phase. (Pratyush is
working on HugeTLB preservation and can explain further).

Not sure I really follow the design here, but in my understanding the gist
here is that hugetlb reservations need to be aware of the preserved state.
If that's the case, we definitely can move liveupdate_init() to an initcall
and revisit this when hugetlb support for luo comes along.
 

Pasha

-- 
Sincerely yours,
Mike.