Re: [PATCH 2/9] kho: Make bootmem reservations visible to fleet monitoring

[Mike Rapoport <rppt@kernel.org>]

Hi Chris,

On Fri, Nov 13, 2026 at 12:30:59AM -0800, Chris Down wrote:
> Hi Pasha,
> 
> Pasha Tatashin writes:
> > > The reservation varies with the kernel, memory size, NUMA layout and
> > > command line. Our fleet collector needs the actual size from each host
> > > so we can decide where to enable KHO and catch a kernel release that
> > > takes those hosts over their bootmem budget.
> > 
> > HM, that works for cold boot not for live update :-)
> 
> Yeah, that's true :-) A kernel we live update into just inherits the areas, so
> we'd only see a release change the size once hosts cold boot into it. I'll say
> that in the changelog in v2.
> 
> > > Today the collector would have to sum kho/out/bootmem_len in debugfs,
> > > which isn't a userspace ABI. In /proc/meminfo, free bootmem contributes
> > > to CmaFree, but the reservation doesn't contribute to CmaTotal. The cma
> > 
> > Is this a different bug?
> 
> I think so, yes. Bootmem pageblocks are MIGRATE_CMA, so their free pages are
> counted in NR_FREE_CMA_PAGES, but totalcma_pages only counts the areas that
> mm/cma.c knows about.
> 
> zone->cma_pages is a separate problem. It only gets bootmem added by
> init_cma_reserved_pageblock() in kho_init(), and on a KHO boot we return before
> we get there.
> 
> I can send patches for those separately if you agree that bootmem should be
> counted in both.

Yes, please :)

> It wouldn't give us the bootmem size though, because CmaTotal
> would still include any other CMA areas.
> 
> > I have some concerns about exposing this as a stable API. What if we get
> > rid of bootmem or make it resizable? We only recently renamed it from
> > scratch to bootmem, and we have been exploring for way to optimize it.
> > 
> > I would keep this exposed under /sys/kernel/debug/kho/bootmem_size for
> > now, and not worry about it being stable.
> 
> That's fair. I'll move it to /sys/kernel/debug/kho/bootmem_size in v2, and we
> can look at sysfs again once bootmem has settled down.

The sysfs vs debugfs argument applies to anything KHO/LUO right now.

But we'll need sysfs at some point to lift the requirement for debugfs
mount.
 
> > Keeping it together with the rest of KHO code would be better.
> 
> Will do, it'll go in kexec_handover_debugfs.c next to the other bootmem files.
> 
> The kho_incoming files in 6/9 are already in kexec_handover.c, but kexec_core.c
> still adds the group to /sys/kernel/kexec. Is that ok, or would you rather KHO
> set that up itself as well?

We'll need sysfs at some point to lift the requirement for debugfs mount.
And I think it can live in /sys/kernel/kho and there we can have incoming
and outgoing and the implementation can be in kernel/liveupdate/kho-sysfs.[ch]

BTW, kexec_handover_debugfs.c was initially given the "full" name because
it lived along kexec_* in kernel. These days I believe we can make it
kho-debugfs.c

I promise to look at the rest of the series Really Soon :)

> Thanks!
> 
> Chris

-- 
Sincerely yours,
Mike.