Re: [LSF/MM/BPF TOPIC] Discussion: Targeted memory allocation via debugfs

[Juan Yescas <jyescas@google.com>]

On Wed, Apr 8, 2026 at 12:47 AM David Hildenbrand (Arm)
<david@kernel.org> wrote:
>
> On 4/8/26 02:12, Juan Yescas wrote:
> > On Mon, Mar 23, 2026 at 2:14 AM David Hildenbrand (Arm)
> > <david@kernel.org> wrote:
> >>
> >> On 3/19/26 01:56, Juan Yescas wrote:
> >>> Thanks David for you comments,
> >>>
> >>>
> >>> On Mon, Mar 16, 2026 at 8:52 AM David Hildenbrand (Arm)
> >>> <david@kernel.org> wrote:
> >>> You’re right that going OOT would bypass the strict API stability and
> >>> extensibility requirements that come with being in-tree.
> >>>
> >>> However, there are some symbols that we would need to be exported in
> >>> order for the module to compile.
> >>
> >> Reason I am asking is because we had similar discussions around memory
> >> hot(un)plug in the past, where we decided that an OOT kernel module to
> >> simulate add/remove was a better choice than exposing weird APIs to user
> >> space.
> >>
> >
> > Hi David, I apologize for the late reply. It’s been a bit of a
> > whirlwind over here with some internal issues.
> >
> >> Which symbols would you need?
> >
> > These are the required symbols:
> >
> > ERROR: modpost: "cma_alloc" [page_alloc_debugfs.ko] undefined!
>
> cma_alloc() will be exported soon:
>
> https://lore.kernel.org/r/20260331-dma-buf-heaps-as-modules-v4-5-e18fda504419@kernel.org
>

Excellent, cma_alloc() and cma_release() will come in handy for this usecase :)

>
> > ERROR: modpost: "migratetype_names" [page_alloc_debugfs.ko] undefined!
>
> I'd assume that you can work around that?
>

That's true, we can just hardcode the strings.

> >
> >  > I guess we'd want to call the buddy by
> >> specifying node+zone+order.
> >>
> > That's correct, for the no cma allocations we'll call "alloc_pages_node_noprof"
> >
> >> Is specifying the migratetype really relevant?
> >>
> >
> > Yes, we want to be able to allocate these types of memory:
> >
> > MIGRATE_MOVABLE,
> > MIGRATE_RECLAIMABLE,
> > MIGRATE_CMA,
> >
> > When the request is for MIGRATE_CMA, the "default_cma_region" will be
> > used for that allocation.
> >
> >>>
> >>>
> >>> Yes, that is actually one of our goals. We often encounter
> >>> "heisenbugs" that only manifest
> >>> under specific workloads and we want the ability to stress the memory subystem.
> >>>
> >>> For example, if we want to increase the unmovable allocations by 16 MiB,
> >>> a 4 KiB kernel, we can do
> >>>
> >>> $ for i in {1..4} \
> >>> do  \
> >>>   echo 1 > /sys/kernel/debug/mm/node-1/zone-Normal/order-10/migrate-Unmovable/alloc
> >>
> >> How will we handle unmovable allocations ending up on movable memory
> >> (e.g., ZONE_MOVABLE)? (e.g., allocating from ZONE_MOVABLE)
> >>
> >
> > Once the allocation is requested using
> >
> > echo 1 > /sys/kernel/debug/mm/node-1/zone-Normal/order-10/migrate-Umovable/alloc
> >
> > We don't care whether the allocation comes from movable/cma memory.
>
> Well, you should.
>
> If you end up doing something like
>
> echo 1 >
> /sys/kernel/debug/mm/node-1/zone-movable/order-10/migrate-Movable/alloc
>
> You are just breaking ZONE_MOVABLE guarantees. Or what am I missing?

I see. How should the ZONE_MOVABLE allocations be handled? Should they
be excluded?

>
> >
> >> Also, is there any reason why we can't do it similar to hugetlb and use
> >> a simple "nr_pages" variable, that can be set and read.
> >>
> >
> > We could use a "nr_pages" variable, but we would also need to set the
> > node, zone and migrate type.
> >
> > It would be cumbersome and error prone to have something like this:
> >
> > echo "Node1/zone-Normal/MIGRATE_RECLAIMABLE/8" > /proc/kernel/debug/mm/nr_pages
>
> I meant something like:
>
> echo 1 >
> /sys/kernel/debug/mm/node-1/zone-Normal/order-10/migrate-Umovable/nr_pages

Got it, we can do something like that. It makes more sense.

>
> (not sure if we really want to specify the migratetype)
>

The migrate type is important because we want to make both MIGRATE_CMA
and MIGRATE_RECLAIMABLE allocations.

Thanks David for your comments.

> --
> Cheers,
>
> David